un 
A 
a 
"gy 
3 
5 
s 
5 
a 
3 
naty] 
hag 
a 
5 


IV. / 08. szám 
Era 


1800 


ISSN 1586 


III 


09.771 


185 


eu dt 
l vi ÉV; ír 


Microsof SZAKENNE szazadi ti 2 Jő 
7hép 





Tudja-e, melyik számban írtunk 


szerkésztőség; az Ont érdeklő témakörökről? 
Főszerkesztő: Fóti Marcell" Nr 
marcellfőnetacademlanet Ú Ez ma már fogas kérdés! Eddigi 


Főszerkesztő-helyettes: Fülöp Miklós 


mickGnetacademia.net működésünk eredménye 


A szerkesztőség címe: 


1062 Budapes, Madrásy úh 62 több mint 300 cikk, több mint 


Telefon: 472-1214 


technetőnetacademia.net 1300 oldalon [ 


Nyilvános levelezési lista: 


tech.netőtechnetklub.hu 


Kiadja és terjeszti a A lapozgatás már nem segít. 
NetAcademia Kft. agit gát; . 
Terjesztési, előfizetési információ: Használja vadonatúj, tematikus 


Telefontázastól keresőrendszerünket a 


terjesztesginetacademia.net 


Megjelenik havonta, ára 1.344 Ft 
NetAcademia O Copyright 2003 


u 
Minden jog fenntartva, beleértve 
(a részleteket illetően is) 
a sokszorosítás, a nyilvános előadás, 
fordítás jogát. A magazinban közölt 


cikkeket, képeket és illusztrációkat a 


kiadó engedélye nélkül közölni, 


e ina 
reprodukálni tilos. 
Előfizethető megrendelőlevélben a 
u 


szerkesztőségnél: 





1062 Budapest, Andrássy út 62. 

Fax: 472-1215 
http://technet.netacademia.net/subs htt p : / / www.netacademia.net / 
Hirdetésfelvétel: Szívós Éva 


Telefon: 472-1214 


ENTYEZTTTTETETHTEETNTTETETTTT 


Fax: 472-1215 





infogonetacademia.net JHdg4 Saren 577 Famaten edjtress 
KÜ 7 





Nyomdai előkészítés: ! NEtACADEMIA 


Ars Luna Bt. ! A UEGIOBBAKAT TANTTTUK 





: aes ovorszteg, 
Vezető: Dobák Ildikó Tudástár — Rendszergazdaltani. — Fefesztötant — Könferenciék — technetmagazin —ketötöközpont — Magunkról 





NetAcademia Tudástár 


9. wndows 7000, Windows NET Server 9 vet feltesztés 
Nyomda: z 5 


AduPrint Kiadó és Nyomda Kft. 
1061 Budapest, 
Paulay Ede utca 55. 


Felelős vezető: Tóth Béláné 


ISSN 1586-5185 


felelőtlen felelősük 


Slimmer: a világ legveszélyesebb férge... 


Újabb mérföldkőhöz érkeztek az SOL Server (--MSDE) eladások. Az üzembehelyezett rendszerek 
száma meghaladta azt a bűvös számot, ami felett már érdemes akár réges-régen befoltozott 
biztonsági hibákra is kódot építeni. E havi bevezetőmben a felelősöket és a felelőtleneket egyaránt 


megnevezem! 


Paradox módon az anyósomtól értesültem a féreg felbukka- 
násáról. Nem azért, mert ő akkora számítógépguru, hanem 
mert alaposan figyeli a sajtót, ami rólam korántsem mondha- 
tó el. (Ha mindenki annyit nézné a tévét, mint én, a nézett- 
ségi index konstans nullát mutatna — Nagy Testvér ide vagy 
oda.) Az eset hétfő reggel történt. Izgatottan ütöttem laptopo- 
mat (a Smart Card bejelentkezési cikket írtam éppen), amikor 
anyósom közölte velem, hogy féreg támadta meg az SOL 
Servert. Ezeket a szavakat még semmilyen szóösszetételben 
nem hallottam tőle, ezért mindjárt gyanakodni kezdtem, 
hogy humbug az egész. És nem. 


2003 január 26-án valóban leállt a szupersztráda. Denial of 
Service támadásnak hívják, amikor a rendszerek — túlterhelés 
vagy egyéb akadályoztatás következtében -— képtelenné vál- 
nak feladatuk ellátására. Pontosan ez történt. Most megtud- 
tuk, mire képes egy alig 400 bájtos kis bigyó. Ráadásul — bár 
lehetősége lett volna rá — fizikai kárt nem is okozott. (Felte- 
hetőleg azért nem, mert az a része még nem készült el, de 
már kiszabadult.) 


Buffer Overrun (BO) 


Mi lehetővé teszi, hogy illetéktelenek távolról tetszőleges kó- 
dot futtassanak gépünkön? Egy programozói hiba. Az elmúlt 
hónapban azon ügyeskedtünk (SOL Injection), hogy kódot 
tároljunk adatként. A BO ennek fordítottja: adatot futtatunk 
kódként. Hogyan? 

Vegyünk egy kódrészletet egy nemlétező, bár Windowsos 
programnyelven. (Már programnyelveket is készítek! Felhív- 
nám a figyelmet a kommentkarakterre. Igazán programozó- 
barát, nemde?) 


msgbox negyzet(3) HAH függvényhívás 


function negyzet (a) ! 
semmi string[221] ama lokális változó. j 
negyzet-ata 

endfu ! 


A függvény meghívásakor a veremre (stack) kerül az átadott 
változók címe, majd a visszatérési cím (és a stack pointer ott 
is marad). Ezt követ(hetjik a lokális változók, szintén a ve- 
remben. (Ezeket a bázispointerrel szokták matatni, hogy a 
stackpointer mindvégig a visszatérési címre mutasson, így 
akármikor ki lehet szállni a függvényből.) Mindezek az ada- 
tok , fejjel lefelé", denevérperspektívában kerülnek a verem- 
be, mert a veremkezelő utasítások (Push, Pop) így látják a vi- 
lágot. De van itt két bökkenő: 

1. A tárolás helyétől és sorrendjétől függetlenül a változókat 

normális" irányban töltjük meg adattal 
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2. Ha nem figyelünk, egy túltöltött változó simán felül- 
írhatja a veremben felette található mentett adato- 
kat. 

Ennyi. Ha genegfelelő" hosszúságú és kialakítású adatot 
tömünk a ,semmi" nevű változóba, az szépen felül fogja 
írni nemcsak az összes lokális változót, hanem a felette 
lévő visszatérési címet is. Ha a címet ,megfelelően" ütjük 
felül, a függvény végén a RET utasítás nem a hívóhoz re- 
pít vissza, hanem oda, ahova akarjuk — tipikusan a stack- 
re, hisz oda tudunk kódot írni. 

Itt jegyzem meg, hogy menedzselt kód esetén mindez 
nem történhet meg. Hajrá .NET! 


Felelősök 


1. Felelős a Microsoft, mert nem két-három évvel ko- 
rábban hirdette meg a Trustworthy Computingot. Ez a 
pár év késés pontosan elegendő volt ahhoz, hogy olyan 
örökség halmozódjon fel, ami évekre ellátja a Tisztelt 
Fogyasztókat megfelelő számú és mennyiségű buggal. 
Most már hiába kapálódzik, a múltat eltörölni nem le- 
het, a régi vevők fele sem telepíti a javításokat. 

2. Felelős mindenki, aki a maga pucér mivoltában SOL 
Servert helyez a netre. Ez az eljárás menthetetlenül hi- 
bás. Emlékszem egy esetre (pár éve történt), amikor az 
egyik hazai vállalat kérésére távolról megnéztem, 
mennyire biztonságos a rendszerük, és találtam egy sa- 
val, üres jelszóval nyíló SOL Servert. Gyorsan csináltam 
rá egy ,A" nevű adatbázist (CREATE DATABASE A), 
ami a mai napig ott van, mert senki nem tudja, hogy ke- 
rült oda, és mi célt szolgál. 

3. Felelős az is, aki Buffer Overrunnal játszik. Valószí- 
nűleg az történt, hogy miután a Microsoft tavaly nyilvá- 
nosságra hozta a hibát, lelkes amatőrök megpróbálták 
kihasználni a lehetőséget. A kód félig sem készült el: 
egyedül terjedni tud. Még az is lehetséges, hogy a leg- 
első működő példány szabadult el, a fejlesztők nem kis 
bánatára. Nem véletlen az időzítés sem: január vége az 
egyetemistáknál még a téli szünet része. Akár én is csi- 
nálhattam volna, mert a Security Workshop részeként 
be szoktuk mutatni a Buffer Overrun működését, igaz 
nem SOL Serveren, hanem RRAS-on, és nem féreggel, 
hanem egy CMD.EXE elindításával — ami azután nem 
csinál semmit. Sem rosszat, sem jót. 


Fóti Marcell 

marcellfonetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 
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Web Browser 
(Internet Explorer 5 


Haladó IWebDav-ismeretek crlater) ——] WebDAV Reavest ) Exchange 2000 
Jelen cikkben az Exchange 2000 adatbázisának alacsony tt  Ehangó 
szintű elérését mutatom be. A cikk első részében egy rövid Store 
betekintést kínálok azoknak, akik vagy újak az Exchange RAS ke E 
szerteágazó világában, vagy még semmiféle kapcsolatot 
nem alakítottak ki vele. Itt lesz szó az ADO használatáról, majd a cikk második (hosszabb) részében bővebben kitérünk a 


WebDav protokollra, amely az adatbázis elérésének leguniverzálisabb és talán legbonyolultabb módja. 





Szám / 


MEL 2002 


Konferenciabeszámoló 


Windows.Net A MEC korábban a Microsoft Exchange Conference kifejezés rövidítése volt, 

technológiák amely később átalakult Microsoft Exchange and Collaboration-re. Azonban idén 
már nem vesződtek a bejáratott MEC megnevezés blikkfangos értelmezésével, a 
konferencia hivatalos leírása ez volt: , The essential Microsoft conference for 
planning, deploying and managing a connected infrastructure" . 
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Tadanéy AUTD Seven 


Microsoít Exchange server 2003 té 7. 


A projekt, amit valaha Titaniumnak hívtak ES FE 
Hamarosan elkészül az Exchange következő változata, tele szá- ( Perimeter Network.) szösá STER 
mos újdonsággal. Outlook Cached Mode, RPC over HTTP, újrairt ss cmrot yssső a í a d 
Outlook Web Access, integrált mobilszolgáltatások hogy csak is § 
néhányat említsünk. Valóban van még új a nap alatt? Tudósítónk Backgronad TETT se ím 4 
jelenti Redmondból. ip LES Hdt 


ty NET AD / GC 
(HTTP / HTML) Server 


PPC-PE. 4 
Smartphone, Windows 2K or 
3" Party Syuc 


Microsoft Exchange 2000 


Nyilvános mappák replikációja 





, BF reterrals" serzsax S PF relerrals" Kis szünet után folytatjuk az Exchange 2000-ről szóló sorozatot. Ebben a részben a 
SSL SZ. nyilvános mappák replikációjával ismerkedhet meg a kedves olvasó. Megvizsgáljuk, 
" xi üg 4 aan Ai 2 4) e 
? mi áll a nyilvános mappák replikációjának hátterében, részletesen foglalkozunk a 


replikáció folyamatával, a konfliktuskezeléssel, valamint a hibaelhárítással is. 
Los Angeles. Moszkva 


Az Exchange 1055 elérése az 595 keresőmotorjával 


Az Exchange 2000 és a SharePoint Portal Server külön-külön is rengeteg előnnyel 
és funkcióval rendelkezik. Ebben a cikkben azt mutatom be, hogy milyen le- 
hetőségek tárulnak elénk, ha a két szervert ,összeházasítjuk". 
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Változó dimenziók kezelése Új] 


A vállalati adatraktárak időben általában stabilak, azaz többnyire csak új adatok- 

kal bővülnek; a tények elemzésére szolgáló dimenziók azonban idővel megvál- 
tozhatnak. Az eladások adatait elemezhetjük például a , Kereskedők" dimenzió 

szerint. A cég kereskedőinek adatai azonban személyes okokból, vagy szervezeti átalakí- 
tás következtében megváltozhatnak. Az ilyen dimenziót szokás , lassan változó dimenzió- 
nak" nevezni. 












PitázhesCstfcster ]/ Memberüt ) Didin [/ Otieci ]  Scczíty 
Enérorment] 0 Sesom 


Feltörhetetlen bejelentkezés? Sem sz. 


zer logon name 


Challenge/Response, Kerberos és Smart Card logon zta 


NETACABEMtan em 


A szoftveripar nagyjai má ígérté ünk, h indenk. é 
szoftveripar nagyjai már sokszor megígérték nekünk, hogy egyszer s mindenkorra véget Ze zize ezé 


vetnek a bejelentkezési (autentikációs) adatok lopkodásának. Ismerjük a LanMan/NTLM 
páros szomorú sorsát (LOPHTCrack), s most már az utóbbi években folyamatosan magasz- 
talt Kerberost is utolérte a sorsa (Kerbcrack)! Egyetlen megoldási lehetőségnek a jelszavas 
bejelentkezés kiiktatása, elfelejtése látszik. Az intelligens kártyás bejelentkezés az új ígé- 
ret. Ez azonban - elődjeitől eltérően — be fogja váltani a hozzáfűzött reményeket, mert... 


Fukishod Certőcatos ] Merborof [/ Disin [/ kiset [7 Secuily 
en zLETET LEE Srnart Lard logon 
Lépésről lépésre 
Najaink legmegbízhatóbb felhasználóazonosítási módszere az intelligens kártyás beje- 
lentkezés. Ha a megfelelő hardvereszközök rendelkezésre állnak, neki is láthatunk a 
rendszer bevezetésének. Szükségünk lesz Certificate Serverre, egy Smard Card-író ,mű- 
helyre", csoportos házirendek állítgatására és még sok minden másra. Ha bármelyik lé- 
pést kihagyjuk, egzotikus hibaüzenetekben gyönyörködhetünk. Ez a cikk a Smart Card lo- 


gon elkészítésének ,szakácskönyve"! 








Identitáskezelés 
Hivatalos Microsoft-tanulmány E 


Az összes munkatársra kiterjedő identitások kezelése egy vállalaton belül mindig nagy kihívást 
jelentett. Napjainkban, az Internet és az elektronikus kereskedelem elterjedésével ez a kihívás 
megnőtt, mert a vállalatok és kormányzatok partnereik és ügyfeleik számára is kénytelenek 
hozzáférést biztosítani belső rendszereikhez és alkalmazásaikhoz. 


META et AT éa 


Ötjektum ] 


is SET A Microsoft operációs rendszerek biztonsági tényezői 
SAM VET "I I. rész — Biztonságos hálózati működés 


Az előző cikkben eljutottunk a biztonságos vállalati hálózathasználat alapjaiig. Egy tuda- 
tosan biztonságosra tervezett operációs rendszert ismertünk meg az NT , személyében". 
Sőt! Van címtárunk és néhány jól tervezett hitelesítési protokollunk, öröklődő jogosultsá- 
gaink és stabil fájlrendszerünk is. Mi kellhet még? PKI, a folyamatok követése (naplózás) 
és adatfolyamtitkosítás. 


Teltes hozzáférés 
Mappa bejárása, áj végrehatása 
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naplózási bedlítások akamazása a tán. U( 
ntzs található objektumokra és/vagy 
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Haladó WebDaw-ismeretek / 


Haladó eblav-ismeretek 


Jelen cikkben az Exchange 2000 adatbázisának alacsony szintű elérését mutatom 
be. A cikk első részében egy rövid betekintést kínálok azoknak, akik vagy újak az 
Exchange szerteágazó világában, vagy még semmiféle kapcsolatot nem alakítottak 
ki vele. Itt lesz szó az ADO használatáról, majd a cikk második (hosszabb) részé- 
ben bővebben kitérünk a WebDav protokollra, amely az adatbázis elérésének 
leguniverzálisabb és talán legbonyolultabb módja. 


MV 
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Az Exchange 2000 bemutatása 


Az informatikai világ két nagy pártra szakad: struktúrált és nem 
struktúrált adattárolást helyeslő pártokra, amelyek soha nem 
fogják megérteni, elfogadni egymás nézeteit az adatok tárolá- 
sát illetően. Míg az SOL Server struktúrált adattárolást és keze- 
lést tesz lehetővé, az Exchange Server a nem struktúrált párt 
nézeteit képviseli. Egyszerűbben kifejezve, míg egy SOL fej- 
lesztő az ügyfél követelményeinek hallatán rögtön a CREATE 
TABLE parancs paramétereit és a szükséges kapcsolatok kap- 
csolótábláit látja maga előtt, Exchange-es kollégája másképp 
(nem biztos hogy jobban) közelíti meg a problémát. 

Többen az Exchange Servert mint levelező szolgáltatásokat 
nyújtó alkalmazást ismerik. Ezt az Exchange némileg kibővíti 
egy , Exchange, mint alkalmazás platform" szolgáltatással. Ez 
annyit jelent, hogy az Exchange támogatja a nyilvános mappá- 
iban és postafiókjaiban adatokat manipuláló alkalmazások fut- 
tatását. Szinte minden SOL fogalomnak megvan az Exchange- 
es megfelelője, tehát ebből a szempontból adatbáziskezelőnek 
tekinthetjük az Exchange Servert is. 

Ahogy az előbbiekből kiderült, az Exchange 2000 két külön- 
böző típusú adatbázist foglal magába: postafiókok tárolását és 
nyilvános mappa funkcionalitást nyújtó adatbázisokat. Ez 
utóbbi közös munkaterületet jelent a cég dolgozóinak, míg az 
előbbi minden felhasználó saját adattárát. 


Az Adatbázis szerkezete 


Az Exchange 2000 és 2003 (a következő verziójú Exchange, 
Titanium kódnévre hallgat, amely pillanatnyilag Beta állapot- 
ban áll) adattárolását a Web Storage System nevű szolgáltatás 
oldja meg, amely szolgáltatást a SharePoint Portal Server szin- 
tén, ugyanebből a célból használja. 

Hogy miért WEB Storage System a neve? A jól csengő névben 
szereplő Web szót távoli adatelérési protokolljának köszönhe- 
ti, amely HTTP kérésekbe burkolt XML struktúra, a neve pedig 
WebDAV. A rendszergazdák örömére a tűzfalon belül elhelye- 
zett Exchange eléréséhez elegendő a HTTP port engedélyezé- 
se, és a hálózaton kívülre irányuló kérések esetében sem szük- 
séges külön odafigyelés, mivel minden kommunikáció HTTP-n 
keresztül zajlik. 

A Web Storage System (továbbiakban WebStore) nem struktú- 
rált adatok tárolására és visszakeresésére alkalmas adatbázis- 
kezelő, amely — integrálva az MSSearch indexelő szolgáltatás- 
sal — támogatja a teljesszöveges (fulltext) visszakereséseket. A 
WebStore architektúráját és szolgáltatásait figyelembe véve fő- 
ként dokumentumok és az azokhoz tartozó kísérőinformációk 
tárolására alkalmas, azaz a középpontban a dokumentum áll 
(megoldva a WebsStore-on futó alkalmazások dokumentumai- 
nak tárolását), amelyhez leíróinformációk tartoznak. 


Mivel a WebStore HTTP alapú, logikusnak tűnhet, hogy a 
WebStore-ban lévő minden elem (SOL-es világban rekord) kü- 
lön URL-lel rendelkezik. Az URL a szerver, azon belül az adat- 
bázis, azon belül a mappastruktúra, majd az elem nevéből 
adódik. Így a myexchange szerver public nevű adatbázisában 
lévő MyFolder-ben elhelyezkedő Myltem.doc elem URL-je 
http://myexchange/public/MyFolder/Myltem.doc. Ez így telje- 
sen logikus, nem? 


Exchange 2000 adatelérési lehetőségek 


Visszatérve az Exchange-re: a hosszú évek során sokféle Ex- 
change-adatelérés készült, némelyek közben nevet is változtat- 
tak, így annak, aki ma Exchange-fejlesztésre adja a fejét, ko- 
moly kihívást jelent a különböző feladatokhoz használatos 
adatelérési technikák megkülönböztetése és kiválasztása. Ez a 
cikk nem nyújt effajta iránymutatást más adatelérési technikák 
használatához, csupán a WebDAV-val foglalkozik, amely ed- 
dig a legújabb Exchange adatelérési lehetőség, és használatá- 
val majdnem minden megoldható. 

A következő lista az Exchange 2000 jelenlegi lehetséges adat- 
elérési változatait mutatja be: 

A MAPI (Messaging APD: alacsonyszintű, kliens-szerver 
architektúrájú, RPC-n történő kommunikációt végző, 
eredetileg levelezési szolgáltatások elérésére készített 
protokoll. 

A ADO MSDAIPP (Microsoft OLE DB Provider for Inter- 
net Publishing) provider: WebDAV-ra épülő ADO pro- 
vider, amelynek használatával a WebDAV kérések 
összeállítása elkerülhető 

A WebDAV (Web Distributed Authoring and Versio- 
ning): HTTP-n kommunikáló adatelérési szabvány, 
amely a szerveroldalon futó IIS-sel egy ISAPI kompo- 
nensen keresztül kommunikál. 

A ADO ExXOLEDB (Exchange OLE DB) provider: Csak az 
Exchange szerveren használható OLE DB provider, 
amely a WebStore közvetlen elérését teszi lehetővé 
(ezáltal megspórolva pl. a HTTP kéréseket). Az egyik 
leggyorsabb adatelérési lehetőség. 

A Microsoft Outlook Object Library: MAPI-ra épülő 
komponens, amely magasszintű adatelérést tesz lehe- 
tővé (előnyei: egyszerűbb naptár- és feladatelem keze- 
lés, stb.) 

A Microsoft CDO (Collaboration Data Objects) 1.21 
Library: A MAPI magasabb szintű verziója, amely ADO 
és ADSI használatával éri el az Exchange Servert. 

A ADSI (Active Directory" Service Interfaces): Active 
Directory-specifikus címtárelérési komponens. 

A LDAP (Lightweight Directory Access Protocol): Szab- 


ványos, TCP/IP protokoll felett működő általános cím- 
tárelérési protokoll. 

H CDOEX (CDO for Exchange 2000 Server): Magasszin- 
tű adatbáziselérést biztosító komponens, leginkább le- 
vélküldésre használatos. 

H CDOEXM (CDO for Exchange Management Objects): 
Exchange 2000 adminisztráció programozott eszkö- 
zökkel történő elérését támogató komponens. 


MSDAIPP 


Az MSDAIPP a WebDAV felett elhelyezkedő adatelérési réteg, 
amely némileg leegyszerűsíti az adatok elérését. Hátránya, 
hogy ezidáig csak ADO providerként elérhető, az ADO.NET- 
ben még nem ismert fogalom. Így ha .NET FramewWorkkel dol- 
gozunk, ,wrappelnünk" kell, vagy el kell felejtenünk, és Web- 
DAV-ot kell használnunk. Az ADO-s elérést ezért VB6-os pél- 
dán keresztül mutatom be. Aki WebStore fejlesztésre vállalko- 
zik, elég gyakran összetalálkozhat COM-os kihívásokkal. 

Az MSDAIPP provider nagyban hozzájárul ahhoz, hogy a 
WebsStore-t adatbáziskezelőnek tekintsük: az ADO architektú- 
rájának köszönhetően a keresések futtatása pl. szinte teljesen 
ugyanúgy történik, mint SOL Server esetében, ráadásul a 
WebsStore egy Transact-SOL nyelvhez hasonló lekérdező nyelv 
használatát is támogatja. 

Ahogy SOL Server esetében is tesszük, elsőként kapcsolatot 
kell teremtenünk a szerverrel. Itt meg kell adnunk a használt 
provider nevét, valamint azon mappa URL-jét, amelyhez a 
kapcsolatot kötjük. A kapcsolaton keresztül történő műveletek 
ezen mappa hatáskörén belül kell hogy történjenek (a mappá- 
ban és — rekurzívan — annak almappáiban). 


Dim objConnection As ADODB.Connection 
Set objConnection - New ADODB.Connection 


With objConnection 

.Provider - "msdaipp.dso" 

.Open "http://xch2k0l/public/NagyonTitkosiíratok" 
End With 


Ezzel meg is van a kapcsolatunk. Ha hiba történik kapcsoló- 
dáskor, az Outlook Web Accessnek köszönhetően lehetősé- 
günk adódik az URL gyors ellenőrzésére, amelyet beírva a 
böngészőbe megjelenik az adott mappa tartalma. Ha nem je- 
lent meg, akkor vagy nem létezik (vagy áll a szerver), vagy az 
Outlook Web Access (OWA) nincs megfelelően belőve. A kö- 
vetkező lépés egy lekérdezés futtatása, amely visszaad minden 
olyan elemet a mappánkból, amelynek az IsNagyonTitkos 
mezőjének értéke True. A kódunkat a következőképpen foly- 
tassuk: 


Dim objRecordSet As ADODB.RecordSet 
Dim strOuery As String 


"SOL guery összeállítása. 
strOuery - "SELECT ":DAV:hre£f"-" 4 § 
"FROM 
""http://xch2k01/public/NagyonTitkosíratok"7 " § 
"WHERE ":"TIsSNagyonTitkos"" - true" 


"Ouery futtatása 
Set objRecordSet - objConnection.Execute(strOuery) 


Ha minden jól ment, az objRecordSet objektumban megkap- 
tuk a lekérdezés eredményét, amelyet a szokásos módon be- 
járva feldolgozhatjuk a tartalmát. Az strOuery változóban 
összeállított SELECT parancs nem néz ki túl fényesen, de haté- 
kony azáltal, hogy a dupla idézőjelek alkalmazásával idézője- 
let írhatunk a sztringbe. 


Rövid úton szerzett WebStore tudásunkkal megál- 


lapíthatjuk, hogy a WebStore-ban mappa néven em- ŰR 


legetett fogalom megegyezik az SOL-es tábla fogal- 

mával. A WebsStore , tábla" fogalma viszont bizonyos 
szempontból többet is nyújt az SOL-es táblánál, 

ugyanis lehetőségünk van a mappaszerkezet hierarchikus fel- 
építésére, amely struktúrán rekurzív lekérdezéseket is készíthe- 
tünk. Sajnos ez a feature csak nem-MAPI tár esetén áll rendel- 
kezésünkre, azaz se a nyilvános mappákat, se a levelesládákat 
tartalmazó adatbázisban nem futtathatunk rekurzív lekérdezé- 
seket (lehetőség adódik további adatbázisok létrehozására, 
amelyek nem látszanak az Outlook-ban, ezeket non-MAPI sto- 
re-oknak nevezzük). A következő kódrészlet egy nem-MAPI 
adatbázison végzett rekurzív keresés, amely ugyanabban a 
mappában, ugyanazzal a kapcsolattal működik, csak nem 
"SHALLOW" (sekély) módon, hanem rekurzívan: 


"Deep SOL aguery összeállítása. 

strOuery; — "SELECT /3DAV:hreEts d e 
"FROM SCOPE("DEEP TRAVERSAL OF " § 
"x:http://xch2k01/public/NagyonTitkoslratok""") 
97 ARZÉN 
"WHERE ""IsNagyonTitkos"" - true" 


"Deep guery futtatása 
Set objRecordSet - objConnection.Execute(strOuery) 


Itt a , DEEP TRAVERSAL OF" kapcsoló a különleges, amely 
implicit módon az előző keresésnél is jelen volt, csak a DEEP 
szót ott a SHALLOW helyettesítette, amely csak a megadott 
mappában tesz lehetővé keresést. Ezen kívül létezik még a HI- 
ERARCHICAL traversal, amely az adott mappa alatti almappá- 
kat adja vissza, elemekkel nem foglalkozik. 

Biztosan feltűnt, hogy az előbbi lekérdezésekben a DAV:href 
mezőt kérdeztük le a RecordSetünkbe. Ez a mező az elemek 
URL-jét tartalmazza, amely alapján egyértelműen megnyitható 
az adott rekord. A következő kódsnippet megnyitja a DAV:href 
mezőben megadott rekordot, módosítja egy mezőjét, majd el- 
menti a változtatást. 


Dim objRecord As ADODB.Record 


Set objRecord - New ADODB.Record 
With objRecord 
.Open objRecordSet.Fields("DAV:href") .Value, 
objConnection, adModeReadWrite 
.Fields("IsNagyonTitkos") .Value - False 
.Update 
End With 
Sajnos a WebStore SOL nem teszi lehetővé UPDATE és INSERT 
használatát, az UPDATE-et az előző példa váltja ki, míg az 
INSERT-et ugyanitt az Open metódushívás megtoldva egy 


adCreateNonCollection paraméterrel. 


WebDAV 


A WebDAV kérések összeállítása a WebStore távoli elérésének 
legalacsonyabb szintű, és emiatt legtöbb funkciót nyújtó lehe- 
tősége. Legfőbb jellemzője a platformfüggetlenség, ugyanis a 
WebDAV nem más, mint a szaványos HTTP protokoll kiegészí- 
tése. A teljes párbeszéd az IIS-en keresztül zajlik. Definícióját 
az RFC 2518-as számú szabvány tartalmazza (amely a HTTP 
1.1 szabvány kiegészítése alapvető dokumentumkezelő funk- 
ciókkal)). 

Még itt az elején egy rövid kitérőt teszek, hogy felhívjam a ked- 
ves olvasó figyelmét egy tipikus WebDav-Outlook tervezési 
kérdésre: a Montana MonFlow nevű Exchange alapú folyamat- 
kezelő terméke majd" teljes funkcionalitását WebDav-ra ala- 
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pozva működik. A termék tervezésének kezdetekor 
nagy kérdés volt a jogosultsági modell kérdése, 
ugyanis az alkalmazás felhasználói felülete az Out- 
look-ot kiegészítő COM Add-In-ként kerül megvaló- 
sításra, így a felhasználó szabadon választhat a Cont- 
rol Panelen beállított Outlook profiljai közül, míg a WebDav 
esetében alapértelmezésben a Windows Authentication a nye- 
rő, így a felhasználó két különböző kontextusban szólongat- 
hatja a szervert. Az ilyen kérdéseket jó előre látni. 


Web Browser 
(Internet Explorer 5 
or later) 


URL Reguest 
XSL or HTML 





Exchange 2000 

Server 

Exchange 
Store 





WebDAYV Reguest 
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WebDAV Response 
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A WebDAV kérés címzettje az IIS, amelyen egy ISAPI DLL vég- 
zi a feldolgozást. A kérés lényegi része ezután a WebStore-hoz 
kerül, aki elvégzi a kérésben megfogalmazott műveletet, majd 
ad egy választ. A válasz egy másik XML, amely a kért adatok 
mellett státuszkódot is ad vissza, amelyben információt kapunk 
a kérésünk eredményéről. Vegyünk nagy levegőt, és bukjunk 
alá! 


PROPFIND /public/NagyonTitkosíratok/ 
SzigoruanTitkos.doc HTTP/1.1 

Host: xch2k01 

Content-Type: text/xml 
Content-Length: xxx 

Depth: 0 


c?xml version-"1.0"7?5 

ca:propfind xmlns:a-"DAV:"5 
dca:propsciIsNagyonTitkos/5c/a:prop: 

c€/a:propfind5: 


A fenti csúnyaság egy egyszerű WebDAV kérés, amely egy 
WebsStore elem két tulajdonságának (mezőjének) értékét kér- 
dezi. Mivel a WebDAV platformfüggetlen, a kérést összeállít- 
hatjuk akár a .NET Framework használatával is, amelyre azon 
belül sokféle lehetőség adódik: használhatjuk például az XML 
DOM-ot, valamint a StringBuilder, StreamBuilder, WebReguest 
és WebResponse osztályokat. Kihasználva a WebDAV plat- 
formfüggetlenségét, a kérés összeállítását és a válasz értelme- 
zését megvalósító kódot és tippeket kihagyom, csak magára az 
adatra összpontosítok. 

Elemezzük az előbbi WebDAV kérést: láthatóan két részből áll. 
A felső a HTTP header, amely szintén két részre bomlik: a leg- 
első sora a metódus: 





1 
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1 [/ 


Body: XML body 


PROPFIND /public/docs/myFile.doc HTTP/1.1 


Ezek szerint ez a kérés a PROPFIND metódust szeretné futtat- 
ni, mégpedig a /public/docs/myFile.doc elemen (a WebStore 
világában a dokumentumokat és mappákat egységesen ele- 
meknek nevezzük). A HTTP header következő része a kérés- 


ben szereplő XML adatra és a metódusra vonatkozó különbö- 
ző információkat tartalmazza (pl. az adat típusa és hossza). Ne- 
vezzük ezeket a header-részeket kapcsolóknak: 


Host: xch2k01l 
Content-Type: text/xml 
Content-Length: xxx 


A fejlécből (headerből) hátravan még a Depth kapcsoló, amely 
ha nulla értékű, jelzi a store-nak, hogy csak az adott elem tu- 
lajdonságaira kíváncsi, al-elemre (mert ilyen is van) nem vo- 
natkozik a kérés: 


Depth: 0 


A Depth egy általában minden kérésnél használható kapcsoló, 
amely az adott metódusra vonatkozóan beállítja a művelet 
,mélységét" (hatósugarál. A Depth kapcsolóhoz hasonlóan 
minden WebDAV metódusnak megvannak a maga kapcsolói, 
ilyen a COPY (másolás) esetén az Overwrite (felülírja vagy 
sem), LOCK (tranzakcióindítás vagy elem zárolása) metódus 
esetén a Timeout kapcsoló (amely megmondja, hogy mennyi 
ideig éljen a tranzakció/zárolás), stb. 

A kérés második része egy XML dokumentum (Body), amely a 
kéréshez tartozó adatot, jelen esetben a lekérdezendő tulaj- 
donságok neveit tartalmazza: 


c?xml version-"1.0"?5 

ca:propfind xmlns:a-"DAV:"5 
ca:proprcIsNagyonTitkos/5c/a:prop: 

c/a:propfind: 


Minden metódusnak megvan a saját XML body formátuma. A 
fenti például a PROPFIND metódusé, amely az IsNagyonTitkos 
tulajdonság értékét kérdezi le. Bizonyos metódusokhoz (példá- 
ul MOVE, COPY) nem szükséges body küldése, az eljárás pa- 
raméterei néhány kapcsoló használatával a fejlécben beállítha- 
tók. Példaként XML nélküli változatra, a COPY metódust futta- 
tó kérés a következőképpen néz ki: 


COPY /public/NagyonTitkosiíratok/ 

4 SzigoruanTitkos.doc HTTP/1.1 

Host: xch2k0l 

Destination: /public/EgyaltalanNemTitkosiíratok/ 
4 SzigoruanrTitkos.doc 

Overwrite: T 


A kérést postázva kisvártatva megkapjuk a választ, amely fel- 
építését tekintve ugyanolyan formátumú, mint a kérésünk. 
A válasz feldolgozása először a státuszkód (lásd alább) vizs- 
gálatával kezdődik, majd megfelelő státuszkód esetén az XML 
értelmezésével és annak bejárásával (végigiterálásával) vég- 
ződik. 

Az előbbi PROPFIND metódusunkra a következő választ kap- 
juk a WebStore-tól: 


HTTP/1.1 207 Multi-Status 
Content-Type: text/xml 
Content-Length: xxx 


c?xml version-"1.0" ?s 
sa:multistatus xmlns:b-"urn:uuid:c2f41010-65b3- 
4 11d1-a29f-00aa00c14882/" 
$ xmlns:c-"xml:" xmlns:a—"DAV:"5 
ca:responses 
ca:hrefs 
http: //xch2k01/public/NagyonTitkosílratok/ 
$ SzigoruanTitkos.doc 


c/a:href: 
ca:propstat: 
ca:statuszHTTP/1.1 200 OKc/a:statusz 
Lca:pPrOp: 
20 63 , 2 


sIsNagyonTitkos b:dt-"boolean"21c/IsNagyonTitkosz 
€c/a:prop: 
c£/a:propstat: 
4c/a:responsez 
c/a:multistatusz 
Látható, hogy van egy fejlécrészünk, amelyben státuszkód ol- 
vasható, vannak kapcsolóink, valamint egy XML dokumentu- 
munk, amelynek a belsejében rejtőzik a lényeg, az IsNagyon- 
Titkos mező értéke, láthatóan jelezve, hogy boolean típusú 
adatról van szó. Ez így első ránézésre elég ijesztő lehet, de 
ijedtségre semmi ok, a következőkben egy kicsit elmazsolázga- 
tunk a részleteken. 
Összegezve az előbbieket, a WebDav világában a következő 
fontos fogalmakkal kell tisztában lennünk: 
HI Metódus 
H Fejléc-kapcsoló 
HA XML struktúrák 


WebDAV visszatérési értékek 


Más nyelvekhez hasonlóan a WebDAV-ban is szükségünk van 
metódushívásaink eredményének ismeretére: vajon sikerült-e a 
másolás, vagy miért nem adott vissza értékeket a PROPFIND 
metódusom, stb. A WebDAV-ban ez is a HTTP-hez hasonlóan 
működik, itt a visszatérési értéket Status Code-nak nevezzük. 
Persze minden metódusnak saját, rá jellemző visszatérési ér- 
tékkészlete van. A válaszon belül is létezhetnek különböző stá- 
tuszkódok. Ha például a PROPFIND metódust több mező egy- 
szerre történő lekérdezéséhez használjuk, minden egyes me- 
zőhöz kapunk státuszkódot, így bizonyos mezőkről eldönthet- 
jük hogy azok nem léteznek, anélkül hogy az egész lekérdezé- 
sünk elszállt volna. 

A státuszkódokat a válaszban kapjuk meg. Válaszonként két 
különböző szintű státuszkódot különböztethetünk meg: a kérés 
egészére vonatkozót, valamint az eredmény különböző része- 
ihez tartozókat. Azoknál a metódusoknál, amelyekhez nem 
tartozik XML body, csak a fejlécben szerepel státuszkód (más- 
hol nem is lehetne). Ha tehát a PROPFIND kérésünkre kapott 
válasz státuszkódja 207 (azaz MultiStatus), biztosak lehetünk 
abban, hogy maga a lekérdezés sikeres volt. Ha a válaszon be- 
lüli XML-ben a mezőértékeket tartalmazó node-ok valamelyi- 
ke a 404-es, jól ismert , Not Found" státuszt viseli, az azt jelzi, 
hogy a kért mező nem létezik az adott elemnél, de ettől függet- 
lenül a kérésünk lefutott. 

A státuszkódok három számjegyű számok, amelyek százas 





(200-207-ig) például minden esetben sikert jeleznek, míg a 4- 
gyel kezdődők kliensoldali (pl. nem létező URL esetén), az 5- 
össel kezdődőek szerveroldali hibát jeleznek, stb. A következő 
válasz egy nemlétező URL-re mutató kérés eredménye: 


HTTP/1.1 404 Not Found 
Content-Type: text/html 
Content-Length: xxx 


Íme egy példa egy olyan lekérdezésre, amely sikeresen lefutott, 
de a két lekérdezett mezőből az egyik nem létezik: 


HTTP/1.1 207: Multi-Status 
Content-Type: text/html 
Content-Length: xxx 


c?xml version-"1.07?5 
ca:multistatus xmlns:b-"urn:uuid:c2f41010-65b3- 
$ 11d1-a29f£-00aa00c14882/" 
4 xmlns:c-"xml:" xmlns:a-"DAV:"5 
ca:responses 
ca:href: 
http: //xch2k01/public/NagyonTitkosíiratok/ 


d Ria 


b SzigoruanTitkos.doc 
c/a:href: 
ca:propstat5: 
ca:StatuszHTTP/1.1 200 OKc/a:statusz 
La:prop: 
cIsNagyonTitkos b:dt-"boolean":1 
c/IsNagyonTitkosz 
c/a:propz 
c/a:propstat: 
sa:propstat: 
ca:statusz 
HTTP/1.1 404 R. rce Ni d 
c/a:statusz 
ca:proprcMennyireTitkos/:c/a:prop: 
£/a:propstat: 
€c/a:responsez 
c/a:multistatusz 


A válaszból látható, hogy minden DAV:propstat (a példában 
a:propstat: hogy miért, arról később szó lesz) XML tag-hez tar- 
tozik egy DAV: status tag, amely a mezőérték lekérdezésének 
sikerességét mutatja. A WebDAV ezen felül intelligens is, mert 
a válasz XML-részében az egy státusz alá tartozó eredménye- 
ket csoportosítva, ezüsttálcán teszi elénk: 


ca:responses 
sa:hrefo:http://szabodnet/public/Test/asd.EML 
c/a:href: 
ca:propstat: 


ca:StatuszHTTP/1.1 200 OKc/a:statusz 
ca:prop: 
cIsNagyonTitkos b:dt-"boolean":1 
c4/IsNagyonTitkosz 
€/a:prop: 
c/a:propstat: 
ca:propstat: 
ca:Statusz 


HTTP/1.1 404 Resource NotFound 
c/a:sStatusz 
ca:prop: 
sc:EzNemLetezik/2 
sc:EsEzSemLetezik/2 
4/a:prop: 
c/a:propstat: 
c/a:responsez 


Csodálatos! A státuszkódok végére érve egy kis varázslat isme- 


rete jól jöhet, ez pedig nem más, mint a Brief kapcsoló hasz- 
nálata: a 


Brie€:. t 

alkalmazásával (a kérés fejlécében) PROPFIND és BPROP- 
FIND (több elem ugyanazon mezőinek lekérdezéséhez hasz- 
nálatos) esetén eltekinthetünk a nem-OK státuszú, PROP- 
PATCH és BPROPPATCH esetén az OK státuszú DAV:propstat 
XML tag-ektől, magyarul megfogalmazva a kapcsoló haszná- 
latával elérhetjük, hogy csak a legérdekesebb válaszokat kap- 
juk meg. 


Összegezve a WebDAV státuszkódok világát: megtudtuk, hogy 
minden válasznak van egy fő státuszkódja. MultiStatus (több 
valválaszt", pl. több lekérdezett tulajdonságot tartalmazó vá- 
lasz) esetén a válasz minden külön részéhez tartozik további 
státuszkód. Azt is megtudtuk, hogy minden metódushoz meg 
vagyon írva, hogy milyen státuszkódok jelentik a sikert és a ku- 
darcot, de az biztos, hogy a kettővel kezdődők jót jelentenek, 
a néggyel vagy öttel kezdődők pedig rosszat. 


Az XML felépítése 


Mivel az XML-t már mindenki jól ismeri, felesleges a válasz 
XML részének bonyolultabb elemzése. Ami furcsaságszámba 
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mehet, az a névterek használata. Röviden: ez az a 
dolog, amitől csúnyán néz ki az XML. Hosszabban: 
az egész ott kezdődik, hogy a WebStore az elemek 
mezőit névterekbe csoportosítja, vagyis a WebStore- 
on futó alkalmazások több ajánlás mellett meg kell 
feleljenek annak is, hogy az általuk kreált mezőnevek tartal- 
mazzák a gyártó cég nevét, az alkalmazás nevét, majd ezután 
a mező nevét. Egyszerűbben előadva: a RépaSoft nevű cég Ré- 
pa 2003 nevű terméke által létrehozott dokumentumok State 
(amerikai címekben államot tároló) mezőjét a következőkép- 
pen javasolt elnevezni: http:/www.repasoft.hu/repa2003/Sta- 
te. Ennek köszönhetően a mező nem fog összekeveredni egy 
másik, ezt az ajánlást be nem tartó cég State nevű mezőjével, 
amelyben az adott dokumentum jóváhagyásának állapotát tart- 
ják számon. Ebből következik a WebDav kérés és válasz XML- 
dokumentumában a névterek használata: a következő válasz 
DAV:multistatus (a válasz legfelső szintű) node-ja felsorolja a 
válaszon belül előforduló névtereket, összerendeli őket egy rö- 
vid, egybetűs azonosítóval, majd az XML további részeiben 
már csak a rövid nevekre hivatkozik. 


csa:multistatus 





A WebStore saját mezőneveinél is a fent írt szabványt követi, a 
http://Schemas.microsoft.com/exchangessecurity/ névtér például 
jogosultsággal kapcsolatos információk tárolására használt me- 
zőket fog össze, míg a http://schemas.microsoft.com/exchan- 
ge/events/ névtér a WebStore eseménykezelésével összefüggő 
mezőket. Az előbbiekhez hasonlóan a DAV: is önálló névtérnek 
számít, amely alapvető adatelérést biztosító és hierarchikus in- 
formációkat tároló mezőket foglal magába. A WebDAV tehát ki- 
használja az XML 1.0 szabvány névterekre vonatkozó előírása- 
it, a WebStore névtér fogalmával megfeleltetve azt. 

Érdemes még egy-két szót szólni az XML-adattípusokról: ami- 
kor boolean típusú mezőértéket kérdeztünk le, a WebStore ezt 
jelezte felénk (ugyanígy jelezve volna, ha numerikus vagy dá- 
tumtípusról van szó). A válasz a következőképpen nézett ki: 


ZTANAGYOATÉLKÓS b:dt-"boolean"51c/IsNagyonTitkosz 
A ,b" névtér alias-nak egy iszonytatóan csúnya neve van (ka- 
paszkodni!): , urn:uuid:c2f41010-65b3-11d1-a29f- 
00aa00c14882/". Hogy ez honnan jött, nem tudom, de való- 
színűsítem, hogy valahol a világ másik oldalán egy GUID ge- 
nerátorból. Ez a névtér jelzi a mező értékének típusát, vagyis 
ha PROPPATCH (mezőmódosítás) metódust használunk, az 
amúgy boolean IsNagyonTitkos mező értékének numerikus 
(példánkban 4 byte-os integer) értéket adhatunk: 


cd:propertyupdate xmlns:d-"DAV:" 





00aa00c14882/"- 
cd:sets 
cd:prop: F 
cIsNagyonTitkos typens:dt-"i4": 
0 
4/IsNagyonTiÍitkosz 
€a/d:propz 
c/d:setz 
ca/d:propertyupdatez 


Ahogy az előbbi példában láthattuk, nem kell minden esetben 
egybetűs névtér aliasokat használnunk, viszont a WebStore 


minden törekvésünk ellenére nem tágít az egybetűs gyakorlat- 
tól. Talán jobb így, nem terheljük a hálózatot. 

A fent látható adattípus elnevezéseket XML-adattípusoknak ne- 
vezzük, amelyek listáját a következő táblázat tartalmazza (az 
,.Mv" a multivalue szó rövidítése): 





(E: 





boolean Logikai érték, 1 vagy 0 értékként 
jelenik meg az XML-ben 
"a . Integer (2-byte) s 
mv.i2 
int Integer (4-byte) 
mv.int 
18 ————— Integer (6-byte) § 
mv.i8 


. dateTime.tz. Dátum és idő 


mv.dateTime.tz 


r4 Lebegőpontos szám (4-byte) 
mv.r4 
. fixed.14.4 Fixpontos szám 5 
mv.fixed.14.4 
float Lebegőpontos szám 
mv.float 
uuid Stringformátumú UUID típus, elválasztó- 
mv.uuid karakterekkel vagy azok nélkül 
. string 2-byte-os Unicode string 
mv.string 
bin.base64 Bináris adat (base64 encoded) 


mv.bin.base64 


WebDav metódusok 


A következőkben rövid bemutatásra kerülnek a WebDav főbb 
metódusai. A B betűvel kezdődő metódusokban a B betű a 
batch szót jelöli, azaz a B nélküli párjukhoz hasonló feladatot 
végzik egyszerre több elemmel. A B betűs metódusok nem ve- 
hetnek részt tranzakcióban (ebben az esetben több B nélküli 
metódushívással lehet megoldani a problémát) 








Metódus Leírás 

COPY, BCOPY Másolás 

DELETE, BDELETE Törlés É 
MOVE, BMOVE Mozgatás 


PROPFIND, BPROPFIND  Tulajdonság(ok) lekérdezése 

PROPPATCH, BPROPPATCH Tulajdonság(ok) módosítása 

LOCK Zárolás vagy tranzakció indítása. 

A tranzakcióban futó kéréseknél fel 
kell tüntetni a tranzakció egyedi 
azonosítóját — 

. Mappa létrehozása e 
A szerver által hívott metódus, amely 
— bizonyos eseményekre történő elő- 
fizetés esetén — értesítést küld a kli- 
ensnek az esemény bekövetkeztekor. 
Az értesítésre használt protokoll az 
UDP (User Datagram Protocol). 
Előfizetés után, az adott esemény 
bekövetkeztének ellenőrzésére, vagy 
a NOTIFY megtörténtének utólagos 
ellenőrzésére szolgáló metódus. 
Mivel az UDP nem biztosítja száz 
százalékosan a csomagok megérke- 
zését, szükség lehet a kliensről indí- 
tott periodikus ellenőrzésre. 


. MKCOL 
NOTIFY 


POLL 











SEARCH Keresés tl elege 
. SUBSCRIBE . Előfizetés bizonyos eseményekre 
UNLOCK befejezés vagy tranzakció lezárása 


(commit/rollback) 
Előfizetés megszüntetése 





. UNSUBSCRIBE 
Előfizetések 


Ahogy az XML mindenki számára ismert fogalom, biztosra ve- 
szem, hogy már mindenki használt OWA-t (Outlook Web 
Access-t) is. Ha igen, abban is biztos lehetek, hogy majdnem 
mindenkinek nagy meglepetésére szolgált élete első OWA-s le- 
vélérkezése, amikor a system tray fölött megjelent az , Új leve- 
le érkezett" felirat (az Exchange Service Pack 2 utáni OWA ké- 
pessége). Ha másnak mégsem, nekem biztosan tátva maradt a 
szám. Ez a csúcsszuper feature a WebDav előfizetésfunkciójá- 
val van megoldva, amelyet megvalósító metódus a SUBSCRI- 
BE névre hallgat. Előfizetni nem nagy varázslat, még XML-t 
sem kell összeállítanunk, csupán a header részben kell néhány 
beállítás, és már mehet is az OWA koppintás! A következő pél- 
dában nem törünk ilyen nagyra, csupán egy mappában törté- 
nő változásra fizetünk elő, 10 perc erejéig: 

SUBSCRIBE /public/GyakranValtozik HTTP/1.1 

Host: xch2k0l 

"Notification-type: Update 


Depth: 1 
Subscription-lifetime: 600 


Siker esetén válaszként szinte ugyanazt kapjuk vissza, mint 
amit küldtünk (200-as státusszal), egy előfizetés-azonosítóval 
(Subscription-id) kiegészítve. Ez az az azonosító, amelyre hi- 
vatkozva, a POLL metódus segítségével megkérdezhetjük a 
szervertől az előfizetésünk állapotát. Ezen kívül lehetőségünk 
van aszinkron értesítés kérésére, ami azt jelenti, hogy ha válto- 
zás történik (vagy bekövetkezik az, amire előfizettünk), a szer- 
ver megpróbál gondoskodni az értesítésünkről (azaz nem ne- 
künk kell megkérdezni, hogy történt-e valami). A ,megpróbál" 
szót azért használtam, mert az értesítés UDP protokoll haszná- 
latával történik, amely nem garantálja a csomag célba érkezé- 
sét. Ez utóbbi értesítést megvalósító metódus neve NOTIFY, 
amelyet minden esetben a szerver hív. A NOTIFY típusú értesí- 
tést úgy tudjuk elérni, hogy a SUBSCRIBE metódusban mega- 
dunk egy Call-Back nevű kapcsolót, amely a kliensünk ,foga- 
dó" címét tartalmazza. A következő válasz egy aszinkron elő- 
fizetésre érkezett: 





Tehát mind a POLL, mint a NOTIFY típusú előfizetést a 
SUBSCRIBE metódussal indíthatjuk, csak a NOTIFY esetében 
egy kapcsolóval többet kell megadnunk. Ha a POLL metódus 
használatával szeretnénk lekérdezni az előfizetésünk állapotát, 
a következő kérést kell összeállítanunk: 





Megjegyzés: a POLL metódust használhatjuk NOTIFY-típusú 
előfizetésnél is. Mivel az UDP-csomagok nem 10099-osan ér- 
nek célba, néha előfordulhat, hogy le kell ellenőriznünk az 
előfizetésünk állapotát. 

A Notification-type (a SUBSCRIBE metódusnál) kapcsoló lehet- 
séges értékei a következők: update, update/newmember, dele- 
te, move, pragma/chttp://schemas.microsoft.com/exchange/ 
newmail5. 


TS Éasazek 
tecnnet é.TETG TT w i 


POLL-típusú Lekérdezésnél a Subscription-ID kap- 


csolóban — vesszővel elválasztva — megadhatunk TD 


több előfizetésazonosítót is. Kérdésünkre a követke- 
ző választ kapjuk: 


HTTP/1.1 207 Multi-Status 
cContent-Type: text/xml 
Content-Length: xxx 


c?xml version-"1.07?5 
ca:multistatus 
xmlns:b-"http: / /schemas .microsoft . com/Exchange/" 
xmlns:a-"DAV:"5 
ca:responses 
ca:href:http://xch2k01/public/GyakranValtozik/ 
c/a:hrefs 
ca:StatuszHTTP/1.1 200 OKc/a:statusz 
cb:subscriptionID: 
clis4c/liz 
€c/b:subscriptionID: 
c/a:responses 
c/a:multistatusz 
A fenti válasz azt jelzi, hogy a 4-es számú előfizetésünk bekö- 
vetkezett. Ha nem következett volna be, a státusza 204 (No 
Content) lenne. Ha több előfizetésre kérdeztünk volna, státu- 
szonként csoportosítva kaptunk volna egy vagy több DAV:res- 
ponse taget. 
Ha lejáróban van az előfizetésünk, lehetőség van a meg- 
hosszabbítására, mégpedig egy olyan SUBSCRIBE metódus hívá- 


sával, amelyhez csak a Subscription-ID kapcsolót mellékeltük. 


Első nekifutásra talán ennyi is elég, a WebStore további izgal- 
mainak felfedezését a kedves olvasóra bízom, ezután csak ki- 
hívásokban gazdag WebStore és Exchange fejlesztést kívánha- 
tok. Egyúttal megragadom az alkalmat, és bátorítok minden Ex- 
change-közeli , építészt" és fejlesztőt WebDav-alapú alkalma- 
zások fejlesztésére. A Montana keretein belül jópár WebDavot 
használó nagyobb méretű, kritikus rendelkezésreállású fejlesz- 
tési projektben részt vettem (pl. VPOP — Vám és Pénzügyőrség 
Országos Parancsnoksága, KBH - Katonai Biztonsági Hivatal), 
és mindezek után az a véleményem, hogy ha valaki jól ismeri 
a témát, az Exchange 2000 (és Titanium) szinte minden funk- 
cióját gyorsan és hatékonyan kihasználhatja. Ezt bizonyítja a 
Microsoft következő generációs Exchange adatelérési kompo- 
nense, amely az XSO (Exchange Server Objects) névre fog hall- 
gatni, és teljesen WebDav alapú lesz. A Microsoft jó szokásá- 
nak az Exchange 2000 esetében is hódolt, elég jó dokumentá- 
ció található az Exchange SDK-ban [1]. Exchange fejlesztői té- 
májú cikkek a [2] oldalakon találhatók. A Microsoft levelező- 
listáin két WebStore szempontjából érdekes cím: [3] és[4]. A 
Microsofton kívül megtalálható site-ok közül érdekes lehet a 
www.wsd2d.com, amely elsősorban a WebStore fejlesztők 
közti kommunikációt támogatja. Az Exchange 2003 (Titanium) 
Beta 2 bemutatója a következő címen érhető el: [5]. 
Szabó Dávid 
szabo.davidomontana.hu 


vezető fejlesztő 
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Konferenciabeszámoló 


A MEC korábban a Microsoft Exchange Conference kifejezés rövidítése volt, amely később átalakult 
Microsoft Exchange "and Collaboration-re. Azonban idén már nem vesződtek a bejáratott MEC megne- 
vezés blikkfangos értelmezésével, a konferencia hivatalos leírása ez volt: , The essential Microsoft con- 
ference for planning, deploying and managing a connected infrastructure" . 


A konferenciáról általában 


2002. október 8. és 11. között a Microsoft Anaheimben (USA, 
California), Los Angeles egyik külvárosában rendezte meg a 
szokásos csoportmunka technológiai konferenciáját, MEC 
2002 elnevezéssel, mintegy 6000 résztvevővel a világ minden 
részéről, persze elsősorban az Egyesült Államokból. 

Noha a konferencia témáinak 50-60 99-a most is az Exchange 
Serverről szólt, már az elnevezés is egyértelműen jelezte: a 
Microsoft számára már nem az Exchange a kizárólagos cso- 
portmunka-platform. Az Exchange mellett a konferencia leg- 
többet emlegetett témája a SharePoint termékkör (mind az 
SPS, mind az STS változat) és a MIS-alapú mobil megoldások 
voltak, de sok előadás foglalkozott sokkal általánosabb téma- 
körökkel (általános rendszermenedzsment, általános fejlesztői 
lehetőségek), mintegy szemléltetve, hogy a Microsoft ma már 
roppant szélesen értelmezi a csoportmunka (, Collaboration") 
témakört. 


Érdekes kettősség jellemezte az egész konferenciát. Egyrészt a 
Microsoft pillanatnyilag a csoportmunkafunkciók koncepcio- 
nális és technológiai újragondolásának fázisában van, nagyjá- 
ból érezve, hogy az eddig roppant népszerűvé vált Exchan- 
ge/Outlook rendszer tartalékai kimerülnek, és 2-3 éven belül 
alapjaiban kell megújulni ezen a területen is. Ezt mutatta, 
hogy meglehetősen kis számban voltak jelen a hosszú távú 
terveket ismertető, koncepcionális előadások (döbbenetes 
volt, hogy a MEC két Keynote előadása közül egyik sem fog- 
lalkozott a Microsoft csoportmunkarendszereinek jövőjével), 
és erre utalt a legbeavatottabbak arcára is kiülő zavart arckife- 
jezés, amikor a meglévő csoportmunkafejlesztések technoló- 
giai jövőjére terelődött a szó. 

Másrészt viszont egyelőre még ezerrel robog a szekér, az Ex- 
change Server-hez már több mint 100 millió (!) klienst adtak 
el, és az mára de facto ipari szabvánnyá, az SAP mellett a 
nagyvállalat IT rendszerek standard alkotórészévé vált. A kon- 
ferencián soha nem látott számú és kifinomultságú Exchange- 
infrastruktúra és üzemeltetési előadást hailhattunk. A kapcso- 
lódó kiállítások is az Exchange-alapú infrastruktúrális és fej- 
lesztési megoldások döbbenetes választékát mutatták. 

A konferencián 6 témakörben 198 előadás hangzott el: 


Collaboration Solutions 
Administration and Management 
Development Tools and Technologies 
Mobility 

Planning and Deployment 

Security 


B88EB5B8B 


Az előadások közül hosszas tanakodás után a rendelkezésre 
álló időt maximálisan kihasználva végül 21 előadást hallgat- 
tam meg. Ezekből nyújtok át egy csokorravalót, tömörített for- 
mában: 


Paul Flessner: The Connected Enterprise (Keynote) 


A konferencia nyitóelőadását Paul Flessner, a Microsoft .NET 
Server portfoliójáért felelős alelnöke tartotta. Érdekes technoló- 
gia víziót láttunk, amely a mindent mindennel (rendszerek, 
emberek, eszközök, üzletek) összekapcsoló funkcionalitáson 
keresztül mutatta be a Microsoft jövőképét. Számomra három 
lényeges információ hangzott el: 


A az Exchange új verziója a Titanium (ejstd: tájténiöm; 
beceneve: Ti - ejtsd: Táj) 2003 közepén jelenik meg 

mA szintén megjelenik az új Outlook (1711-es verzió) 

A formálódik a Microsoft új csoportmunkafejlesztő esz- 
közrendszere, az XSO. 


Brian Murphy: SharePoint Products and Technologies V2 
Overview (TBR250) 


Ez az előadás volt az egyetlen, amely kifejezetten a SharePoint 
termékkör új, 2003 közepén megjelenő változatáról szólt. A 
Microsoft két SharePoint terméke közül a kisebbik testvér, a 
SharePoint Team Services lett a nyerő, úgy tűnik, az új verzió 
teljes egészében ennek technológiai platformjára épít (MS SOL 
Server adatbázis, webes felület, dokumentumkezelési és általá- 
nos csoportmunka funkcionalitás), amelyet most kiegészítenek 
a nagyobbik Sharepoint portál- és keresőfunkcióival. Az új ver- 
zióban már nem lesz technológiai különbség a két Sharepoint 
változat között: a nagyobbik testvér mindent tud, amit a kiseb- 
bik, csak néhány nagyvállalati és Internetes használathoz szük- 
séges , Enterprise" funkcióval egészül ki. 


Windows.Net 
Server 
technológiák 


told 





SOL Server p) 


Látni lehetett, hogy a fejlesztés elsődleges iránya a jobb skáláz- 
hatóságra és a robosztus működésre irányul (természetesen 
. NET technológiai váltással együtt), míg a dokumentumkezelé- 
si és tudásmenedzsment funkciók esetében inkább a szinten- 
tartás dominál. 

Fontos infó volt, hogy az új SharePointnál tovább erősítik a ré- 
gi STS-ben már megjelent nézeteken és egyedi űrlapokon ala- 
puló általános csoportmunka keretrendszert, amely akár az Ex- 
change Server alternatívája lehet. Az előadás után megkérdez- 
tem az előadót, hogy mégis, akkor most az Exchange Server, 
vagy a SharePoint lesz az elsődleges platform a csoportmunka- 
fejlesztésekhez? Enyhén szólva kitérő választ adott, aminek az 
volt a lényege, hogy igazából mind a két eszköz szükséges le- 
het. (A Microsoft maga, házon belül kizárólag az STS-t hasz- 
nálja csoportmunkacélokra, sem SPS, sem Exchange-alapú fej- 
lesztései nincsenek!) 


Jensen Harris: Outlook 11: Overview (TBR200) 


Az Outlook fejlesztői csapatának vezetője (Lead Program Ma- 
nager) ebben az előadásban részletesen ismertette a jövő év kö- 
zepén az új Office részeként piacra 
kerülő Outlook 11 újdonságait. Meg- 
















SharePoint Portal 


tudtuk, hogy az Outlook felhasználói Server (STS) 
felületét alapvetően újratervezték, és s Ad hoc csoport- 

az eddig is a világ egyik legkifinomul- szintű munkaterületek 
tabb UI-jához még egy sor alapvető " Klasszikus 

mié é Áá ű dokumentum- 
újdonságot alakítottak ki. Nagyon tárolás és 


fontos szempont az online és offline csoportmunka 
használat megújítása, amit az előadó 
egy egyméteres drótvágóval kívánt il- 
lusztrálni — sikerrel. A harmadik nagy újdonság, amely az Out- 
lookalapú fejlesztések szempontjából is kimagasló jelentőségű, 
az úgynevezett , Search Folder" funkció megjelenése, amely 
lehetővé teszi a különböző fizikai mappákban levő elemek tet- 
szőleges, virtuális nézetekben való egyesítését. Roppant érde- 
kes volt, ahogy az előadó bemutatta, hogy az új Outlook nem- 
csak az Exchange Serverhez, hanem az új SharePointhoz is ren- 
delkezik közvetlen klienshozzáféréssel, és bizonyos STS-funkci- 
ók az Outlookból is elérhetőek. Az egész előadás egyértelmű- 
en azt sugallta, hogy maga az Outlook továbbra is a Microsoft 
csoportmunkamegoldásainak legfontosabb elemét jelenti, noha 
az előadás után feltett kérdéseimre adott válaszokból kiderült, 
hogy az Outlook fejlesztői környezetnek (Outlook űrlapok, 
VBA) nem tervezik érzékelhető mértékű továbbfejlesztését. 


Leon Warman: Adding People-to-People Workflow to Your 
Solution (CLB340) 


Az előadás a Microsoft Exchange Serverbe épített Workflow le- 
hetőségek jól felépített összefoglalása volt. Végigvette a Work- 
flow-motor, és a tervezőeszköz funkcióit, és néhány példával 
felvillantotta a programozási lehetőségeket is. Tartalmilag nem 
sok újdonsággal szolgált, ezek nálunk már a MonFlow része- 
ként gyakorlatban használt eszközök. Ami érdekes, hogy az 
előadás egyértelművé tette: a személyek közötti (irodai) work- 
flow-megoldásokra a Microsoft továbbra is egyértelműen az 
Exchange-környezetet ajánlja (a BizTalk a korábbi elvárások- 
kal szemben nem vált a people-to-people workflow megoldá- 
sok platformjává — maradt a nagy, automatizált rendszerek fo- 
lyamatainak vezénylőmotorja). 


Terry Myerson: Exchange Product Roadmap (TBR201) 


Bátran állíthatom, hogy ez volt a legérdekesebb előadás az 
egész konferencián, ennek kellett volna az egyik Keynote-nak 








lennie (így is kétszer ismételték meg a nagy érdeklő- 


désre való tekintettel) Terry Myerson, aki a Microsoft A 


Exchange fejlesztői csapat egyik vezetője (Group 

Program Manager) meglehetősen részletesen ele- 

mezte az Exchange Serverrel kapcsolatos, a közeljö- 

vőben tervezett új fejlesztési terveket. 

Először is, hogy mely termékekre épül ma a Microsoft csoport- 
munka stratégiája: a SharePoint Team Services lesz várhatóan 
a dokumentumkezelési és az egyedi csoportmunkafunkciók 
platformja, az SPS a vállalati portálmegoldások és a széleskörű 
keresőfunkciók hordozója, az Exchange pedig a személyes in- 
formációkezelés, és a mobilfunkciók mellett a Workflow-lehe- 
tőségek tekintetében elsődleges. Új elem a Greenwich kódne- 
vű új szervertermék, amely elsősorban az online együttműkö- 
dés platformja lesz. 


Az egész Exchange 2000-történet legsikeresebb része az új 
OWA volt. Állítólag a legtöbb ügyfél, aki az Exchange 2000 
bevezetése mellett döntött, egyik legfontosabb indoknak az új, 
minden eddiginél gazdagabb funkcionalitású Outlook Web 
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Accesst nevezte meg. Éppen ezért a Titanium legnagyobb újí- 
tását mindenképpen a webalapú kliens még komolyabb to- 
vábbfejlesztése fogja jelenti. Az OWA eddig is messze a leg- 
szélesebb funkcionalitású, legkifinomultabb webes levelező- 
kliensnek számított a világon, ám a bemutatott Titanium demo 
már messze meghaladott mindent, amit egy webalapú alkal- 
mazásról valaha is el tudtunk képzelni — noha semmilyen kli- 
ensoldali huncutság (/ava applet, ActiveX, stb) nem támogatta 
ezt — tiszta szerveroldali kód, némi kliensoldalon futó, scripttel 
felturbózott HTML. Hogy csak néhány példát emeljek ki: vég- 
re támogatják a Tasks funkciót, itt is használható lesz a Search 
Folder, teljeskörűvé válik a DraggDrop és a jobb egérgomb 
használata, és működő helyesírásellenőrzés (!) is van a rend- 
szerben (ne feledjük, egy webalapú vékony kliensről van szó!). 
Az egész rendszer felhasználói élménye (elsősorban a sebes- 
ség) sokkal jobban hasonlított a normál Windows-alkalmazás- 
nál megszokott feelingre. (Ez a kis demó valószínűleg betekin- 
tést engedett a jövő webalkalmazásainak világába — ahol talán 
kompromisszumok nélkül válthatják ki a böngészőalapú meg- 
oldások a hagyományosakat...) 

A másik nagy hanggal beharangozott újítás a sávszélességbarát 
működési módot támogató új hálózati kommunikációs megol- 
dás, melynek lényege: 


A az Outlook és az Exchange közötti kommunikációt op- 

timalizálták (csak a legszükségesebb információkat kül- 

di és fogadja a rendszer) 

az adatforgalom tömörített 

az Outlook-kliens automatikus és sima átmenetet ad az 

online és az offline mód között (lásd: drótvágós demó 

az Outlook előadáson) 

A a kommunikáció teljes egészében HTTPS protokollon 
zajlik. 


Es] 
ma 


"2002 JAH / 


OJOMEZSagPI Jaa NOK 


II 


-" Konferenciabeszámoló / 


MEC 2002. 


1 


Az offline használat alapját adó kliensoldali kompo- 
nenst nemes egyszerűséggel csak ,Cached Exchan- 
ge"-nek nevezték. A leírások szerint ennek használa- 
tával 30-7090-kal csökken a hálózati forgalom, 5090- 
kal a CPU terhelés... szerveroldalon. 

A harmadik nagy újdonságot pedig a mindent elborító mobil- 
funkciók integrálása jelenti. A most még külön termékként for- 
galmazott MIS (Mobile Information Server) a következő Ex- 
change verzióban már az alapszolgáltatásokat fogja gazdagíta- 
ni. Az új Exchange-nek az SMS/MMS/WAP szolgáltatásokat 
használó mobiltelefonok, és a drótnélküli hálózatba kapcsolt, 
vagy GPRS kapcsolattal bíró PDA-k éppolyan természetes kli- 
ensei lesznek, mint manapság a PC-inken futó Outlookok. 
Komolyan megújul az Exchange Server üzemeltetési biztonsá- 
gát garantáló eszközrendszer is. A Titanium már akár 8 csomó- 
pontos fürtbe is szervezhető, és teljesen megújított, optimali- 
zált backup-rendszer kapcsolódik hozzá. Emellett végre teljes- 
sé válik a MOM-integráció, és kiteljesednek a biztonsági funk- 
ciók is. 

Az Exchange Server továbbfejlesztése során az egyik leghang- 
súlyosabb terület az Exchange Server fejlesztői környezetének 
megújítása. A CDO-t felváltó új, mindenható hárombetűs rövi- 
dítés az XSO. Természetesen ez már a .NET frameworkhöz il- 
lesztett, nyelvíüggetlen API. 

Az előadás befejezéseként Terry még megpróbált bekukucskál- 
ni a Titanium utáni Exchange fejlesztéseket jótékonyan burko- 
ló homály mögé is. Úgy tűnik, a fejlesztés továbbhalad a sze- 
mélyes információkezelés finomításának irányába: szerverol- 
dalon továbbfejlesztett e-mail, Naptár, feladat és kontaktfunk- 
ciók várhatók. A kérdésekre adott válaszokból az is egyértel- 
művé vált, amit a suttogó propaganda már régóta terjesztett: a 
Titanium utáni új Exchange verzió már új adatbázismotort fog 
használni, ugyanazt, amit az addigra szintén megjelenő új SOL 
Server számára alakítottak ki. 


Mindy Martin: Developing with Exchange Using Visual 
Studio .NET (ADM401) 


Mindy Martin a legnagyobb és legbefolyásosabb Exchange fej- 
lesztési guruk közé tartozik. Mint Program Manager az Exchan- 
ge Server-hez kapcsolódó fejlesztőeszközök kialakításának 
egyik vezetője, és a mind a mai napig az egyik legjobb Exchan- 
ge 2000 fejlesztésekkel foglalkozó könyv szerzője (Program- 
ming Collaborative Web Applications with Exchange 2000 
Server, magyarul is elérhető). 

Ebben az előadásában az új .NET-alapú fejlesztőeszközök Ex- 
change-alapú csoportmunka alkalmazásokhoz történő felhasz- 
nálását járta körül. 

Először végignéztük az Exchange 2000-hez illeszthető .NET 
fejlesztéseket: készíthetünk az Exchange Server szolgáltatásai- 
ra épülő Web Service-eket, illetve használhatunk .NET-es kli- 
ensalkalmazásokat (ASP.NET, Win Forms), és event sinkek is 
kialakíthatók .NET eszközökkel. Ami lényeges: abszolút ellen- 
javalt, és nem támogatott a nyilvános mappákban levő web- 
form-alapú alkalmazások ASP.NET-re való továbbfejlesztése. 


Ha van oly botor e kies hazában, aki ilyesmivel próbálkozott, 
az jobban teszi, ha elölről kezdi a fejlesztést a .NET platform- 
ra való áttérés során... 

Az előadás második részében a most alakuló új Exchange fej- 
lesztői környezet, az XSO lehetőségeit vázolta. Ezt olyan fej- 
lesztési lehetőségnek szánják, amelynek lényege a , managed 
code class library" és különösebb specifikus Exchange szaktu- 
dás nélkül, a .NET nyelvfüggetlen keretrendszerére építve teszi 
lehetővé a fejlesztést a Titanium környezethez. 

Az előadás talán legérdekesebb része az volt, amikor az elő- 
adó elmondta, hogy intenzíven gyűjtik az ötleteket az XSO 
végleges formájának kialakításához. Sajnos az is kiderült eb- 
ből, hogy magát az XSO-t igazából még csak tervezgetik, a fej- 
lesztése csak ezután fog kezdődni. Úgy tűnik, ez nem fog meg- 
jelenni a Titaniummal együtt, csak később, valamelyik szerviz- 
csomagban, vagy egyedi kiegészítésként. 


Egyéb érdekességek 


Scott Jamison, a Dell munkatársa az egyik prezentáció során 
rengeteg gyakorlati példában mutatta be, hogyan lehet az új 
.NET-es technológiákat felhasználva Office-alapú alkalmazá- 
sokat készíteni. Az előadás maradandó mondanivalója volt, 
hogy az Office-nak már a jelenlegi (XP) verziója is ideális front- 
end az XML-alapú webszolgáltatások számára. Ehhez az Offi- 
ce XP Web Sevices Toolkit nevű csomagot ajánlotta. 

Sue Mosher előadásából megtudhattuk, hogy az Outlook néze- 
tek definícióját hordozó információk Outlook 2000-től kezdve 
egy XML-fájl szerkesztésével módosíthatóak. Az előadás gon- 
dosan ismertette ennek kivitelezhetőségét, majd konkrét pél- 
dákkal, kódrészletekkel mutatta be a gyakorlati használatot. 
Matt Gossage az , Exchange 2000: Scalability-Reality vs. Myth" 
című előadásában nagyon gyakorlatias módon, praktikusan 
felhasználható formában tárgyalta a nagy terhelésnek kitett Ex- 
change Server méretezési problémáit és megpróbált eloszlatni 
néhány közkeletű mítoszt. Az Exchange Server számára a szűk 
keresztmetszetet ma általában a memória jelenti. A terhelés fo- 
kozása során először a Windows 2000/Exchange 2000 ismert 
memóriakorlátjába (3 GB a Boot.ini kapcsoló beállításával) fo- 
gunk ütközni. A jelenlegi ismeretek szerint a felhasználható 
processzorok száma, illetve az Exchange Server mögött dübör- 
gő adatbázismotor által kezelt merevlemez területek mérete 
még tovább növelhető lenne, ha nem ütköznénk a memória 
korlátaiba... 

Az Exchange-alapú fejlesztéseknek a memóriakorláton túl 
nincs méret/teljesítményhatára. Az Egyesült Államokban sok 
nagyvállalatnál több száz gigagbájtnyi, milliós léptékű adathal- 
mazokat kezelnek Exchange alapon (CDO, MAPI, WebDAW) 
kifejlesztett egyedi alkalmazásokkal. 


Füzessy Tamás 
Alkalmazásintegrációs és fejlesztési igazgató 
fuzessytomontana.hu 
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Hamarosan elkészül az Exchange következő változata, tele számos újdonsággal. Outlook Cached 
Mode, RPC over HTTP, újraírt Outlook Web Access, integrált mobilszolgáltatások hogy csak néhányat 
említsünk. Valóban van még új a nap alatt? Tudósítónk jelenti Redmondból. 


Merre tovább Exchange? 


Bizony, már három év telt el a Microsoft Exchange 2000 meg- 
jelenése óta. Az 5.5-ös verzió utódja, köszönhetően a mélyre- 
ható Windows 2000 integrációnak, meglehetősen sikeres pá- 
lyát futott be, de hagyjuk most a marketinget... A valóságban 
igenis voltak hullámvölgyek a termék életében, jelenleg az 
SP3-nál tartunk, a korai gyermekbetegségeken — pl. memória- 
töredezettség jelenségek — túljutva, ma már nem kérdés, hogy 
Active Directory környezetben az Exchange 2000 a vezető 
üzenetkezelő platform. 

Kevesen követhették, de ez idő alatt, valamikor egy éve, az Ex- 
change fejlesztői csoport kijelölte a termék következő generá- 
cióinak irányvonalát. A nagy kérdés az volt, hogy a közeljövő- 
ben kifejlesztendő technológiák vajon javítókészletekbe, vagy 
egy új szerververzióba kerüljenek-e bele, illetve mikor történ- 
jen meg a Nagy Váltás: az adatmotor cseréje egy következő ge- 
nerációs adattároló mechanizmusra. A fejlesztők — egyebek 
mellett a közeljövőben megjelenő Office hatására — egy új 
szerververzió kiadása mellett döntöttek, az eredmény egy Ex- 
change Titanium elnevezésű projekt lett. A cél a termékkel 
nem az volt, hogy az alapvető komponenseket (adattár, a kli- 
tások) lecserélje. A fejlesztők sokkal inkább a mobil kliensek, 
lassú elérésű távoli telephelyek támogatását, illetve a Windows 
Server 2003 és Office 11 integrációt jelölték meg elsődleges- 
nek, szem előtt tartva persze, hogy nem árt, ha az adminisztrá- 
torok életét is könnyebbé teszik néhány aprónak tűnő, de na- 
gyon hasznos újdonsággal. 

Mielőtt elmélyednénk ezek megismerésében, álljunk meg egy 
pillanatra. Szép dolgok ezek, gondolhatnánk, de az nem lehet, 
hogy csak egy-két évre képesek előre gondolkodni a redmon- 
di fejlesztők. Nem is ez történt, ugyanis a Titaniummal párhu- 
zamosan elindult egy másik, igencsak ambíciózus projekt, 
melynek célja a szerver (melyet ma Exchange-nek hívunk) tel- 
jes körű újratervezése és integrációja a Microsoft következő 
ciós rendszerével (Longhorn) és produktivitási eszközeivel (Of- 
fice11-). Itt gyorsan le is zárom ezt a szálat, hiszen ezek a 
technológiák leghamarabb 2004/2005 körül állnak 
majd rendelkezésre. Koncentráljunk most a Titani- 
umra, akarom mondani a Microsoft Exchange Server 
2003-ra. 

A termék gyártásra kész állapotát — a Microsoftos 
szleng ezt RTM-nek (release to manufacturing) hívja 
— valamikor ez év júniusában éri el. Jelenleg Beta 2- 
ben van, ami azt jelenti, hogy funkcionális szem- 
pontból többé-kevésbé kész, a júniusig terjedő idő- 
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szakban csak nagyon kevés új szolgáltatás (feature) kerül bele, 
a fejlesztők javarészt hibajavítással és optimalizálással foglal- 
koznak majd. A bátor vállalkozók a mellékletben található 
címről [1] letölthetik, a teszteléshez VMWARE javasolt, a tele- 
pítés előtt a követelmények megismerése és a "release notes" 
elolvasása kötelező gyakorlat! 

Most pedig nézzük az Exchange Server 2003 újdonságait! (A 
hogyan működik" részleteket terjedelmi okok miatt ezúttal 
megvágtam, teljeskörű technológiai áttekintés egy közeljövő- 
ben induló sorozatba kerül majd bele.) 


Amit a felhasználók látnak 


Az Exchange Server 2003 talán legfontosabb kliensoldali új- 
donsága az Outlook11 új , Cached Mode"-ja. Ez az üzemmód 
átmenetet képez az , offline" és ,online" Outlook profilok kö- 
zött. Ha bekapcsoljuk, az Outlook 11 felhasználó nem a szer- 
veroldali postaládáját , látja", hanem annak egy lokális válto- 
zatát, melyet egy intelligens szinkronizációs mechanizmus fo- 
lyamatosan írissen tart. Miért van erre szükség? A választ erre, 
mint sok minden másra, egy ma már idejétmúlt tervezői felfo- 
gásban érjük utol. Az Exchange első verzióinak tervezésekor 
az a felfogás alakult ki, hogy egy tipikus hálózat levelező ki- 
szolgálója és kliensei között folyamatosan jó (LAN) kapcsolat 
van, ha pedig ez nem áll fenn, a lassú vonalakon bekapcsoló- 
dó felhasználók használjanak , offline" profilt és szinkronizál- 
janak a kliens igényei szerint. A fenti filozófiát követve fejlesz- 
tette ki a Microsoft a MAPI protokollt, mely valójában egy üze- 
netkezelő inífrastruktúrákra optimalizált kliens-szerver inter- 
fész. A MAPI egyik fontos tulajdonsága, hogy a konkrét ,inter- 
process" kommunikációra az operációs rendszer RPC mecha- 
nizmusát használja. 
Erre viszont sajnálatos módon az jellemző, hogy közismerten 
kapcsolatérzékeny, azaz a kapcsolat a szerver és kliense kö- 
zött - a hálózati forgalom időleges megszűnésével vagy a ren- 
delkezésre álló sávszélesség drasztikus lecsökkenésével — na- 
gyon könnyen megszakadhat (, timeout-ra fut"). Ekkor persze 
a kapcsolatot újra fel kell építeni, ami hatással van a kliensal- 
kalmazás viselkedésére. Az Exchange kliensek, köztük az 
. Outlook, ezt viszonylag 
nehezen, viselik, a ko- 
rábbi változatok lefagy- 
tak, a felhasználóknak 
újra kellett őket indítani, 
az OutlookXP-ben ekkor 
jelent meg az a hírhedt 
párbeszédablak, amit a 
mellékelt ábrán látunk. 
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Az RPC hibák kultúrált kezelése sajnos a mai napig 
nem megoldott, a fejlesztők szerencsére belátták, 
hogy egy erősen szegmentált, több telephelyes háló- 
zatban az élet nem habostorta, igenis vannak hálóza- 
ti kimaradások, sávszélesség-ingadozások. Különösen 
igaz ez a 802.11b vezeték nélküli hálózatokra, aki kipróbálta 
már, hogyan viselkedik az Outlook a térerősség megszűnése 
után egy WindowsXP-s notebook-on, az tudja mire gondolok. 
Lépni kellett tehát, melynek eredménye az új Outlook Cached 
Mode, ami átvészeli a hálózat bizonytalanságait. Fő erénye, 
hogy a hálózati kapcsolat állapotától függetlenül a felhasználó 
a lehető legfrissebb információkat látja, ha pedig frissítésre ke- 
rül sor, lehetőleg a legkevesebb információ menjen át a ,dró- 
ton". Hogy világos legyen, nézzük, mi történik a háttérben. 

A gyorsítótár üzemmódban az Outlook egy lokális OST fájllal 
tartja a kapcsolatot, melyet egy alacsony prioritású szál folya- 
matosan aktualizál. A mechanizmus alapjaiban más, mint amit 
az , offline" szinkronizáció során megismertünk. A kliens az 
Exchange kiszolgálótól (amennyiben lehetősége van) folyama- 
tosan megkapja változásértesítéseket, ha pedig van ilyen, el- 
kezdi a szinkronizálást. Az újdonság itt az, hogy a frissítés s0- 
rán először csak a fejlécek érkeznek meg, a teljes tartalom csak 
akkor jön le azonnal, ha a felhasználó rákattint egy levélre, ha 
egyébként nem tesz semmit, a szövegtörzs a rendelkezésre ál- 
ló CPU idő és a hálózat rendelkezésre állásának függvényé- 
ben, folyamatosan jön le. Mindebből a felhasználó persze 
semmit sem lát, ő csak azt érzékeli, hogy a postaládáját folya- 
matosan , karbantartják" , függetlenül attól, hogy éppen van há- 
lózati kapcsolata vagy sem. 


AY ezta 


Exchange Server Settings 
You can enter the reguired information to connect to your Exchange server. 


Type the name of your Microsoft Exchange Server computer. For information, see your 
system administrator, 


Microsoft Exchange Server: [excho1 .adatum.com 


Type the name of the maibox set up for you by your adminéstrator. The mailbox name is 
usually your user name. 


User Name: (Ted Bremer 





Check Name 


Run Outlook using a local copy of my Exchange madbox. 
use tocal copy of Madbog 























3 A Cache Mode konfigurálása az Outlook 11-ben 


Érdekes még, hogy a szinkronizáció sem megy , simán", mivel 
az Exchange Server 2003 a leküldés előtt egy GZIP algorit- 
mussal összetömöríti a leveleket. A korai tapasztalatok szerint 
ez RTF típusú üzeneteknél -2090, HTML/Text esetén akár 
-6090-os kompressziót jelent. Az Outlook Cache Mode-dal 
kapcsolatban még egy érdekességet említek: az Outlook 11 
folyamatosan naplózza a sikeres és sikertelen RPC hívásokat, 
amit bármikor megnézhetünk a CTRL billentyűvel a tálca Out- 
look ikonjára kattintva. Mellesleg ezt az információt az Out- 
look folyamatosan felküldi szervernek, amit később az Ex- 
change System Managerben is megtekinthetünk, ahonnan 
akár WMI-n keresztül bármikor kiolvasható, hogy aztán az 
igazán kifinomult adminisztrátorok remek jelentéseket készít- 
senek a levelezőkliensek oldalán érzékelt rendelkezésre állás- 
ról (például MOM-ban). Egyelőre ennyit az Outlook Cache 
Mode-ról, meggyőződésem, ezentúl alapjaiban másként ter- 
vezünk Exchange 2003-as topológiákat, nem lesz szükség kü- 


lön szerverre a távoli, lassú elérésű telephelyeken, nem be- 
szélve arról a mellékhatásról, hogy az új üzemmódnak kö- 
szönhetően a kiszolgálók ugyanazzal a konfigurációval nagy- 
ságrendekkel több Cache Mode klienst fognak tudni kiszol- 
gálni, mint online MAPI-s ügyfelet. Most pedig térjünk át egy 
másik, eddig megoldatlan problémára, nevezetesen hogyan 
kapcsoljunk internetes MAPI klienseket belső Exchange ki- 
szolgálókra. 


Élet a tűzfalon kívül 


A feladat fogós, a triviális megoldás VPN-t konfigurálni, de ez 
nem minden vállalaton megy át , csont nékül". A másik megol- 
dási lehetőség, hogy lefixáljuk és kinyitjuk a MAPI-s RPC por- 
tokat, amit eddig csak a legbátrabb ISA-adminisztrátorok pró- 
báltak. A dolog megoldható, a Techneten van róla információ, 
de nem kultúrált, a részletekbe most nem megyünk bele. Pedig 
milyen jó lenne, ismerve az Outlook Cache Mode képessége- 
it, ha klienseink egy tetszőleges Internetkapcsolat felett is be 
tudnának menni a tűzfal mögötti postaláda-szervereikre, lehe- 
tőleg titkosított csatornán, és persze minimális adminisztratív 
igénnyel a tűzfalasok felé! Nos, erre született a megoldás az 
Exchange Server 2003-ben: RPC over HTTP. Segítségével, 
amint az a nevéből kiderül, egy dedikált front-end kiszolgálót 
(Windows Server 2003) kinevezhetünk ún. RPC proxy-nak. In- 
nen már csak egy lépés, hogy SSL-tanúsítványt kérjünk az Ex- 
change alapértelmezett webjére, publikáljuk a szervert az ISA- 
ban, s máris jöhetnek a Outlook Cache Mode kliensek, szink- 
ronizálás az Internet felől kipipálva. 
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Port reguirements: 
open port 80 (HTTP) 
or port 443 (HTTPS) 


Port reguirements: 
open ports 593 and 
the range of ports: 
1024 - 65535 


a Az RPC over HTTP-infrastruktúra az Exhange 2003-ban 


Böngészés, veszteségek nélkül? 


A szinkronizálás remek szolgáltatás, de mi van, ha a felhaszná- 
lóknál nincs Outlook kliens? A válasz: Outlook Web Access. Ez 
már az Exchange 2000-ben is benne volt, a maga nemében 
egyedülálló megoldásként. A gond csak az, hogy a böngészőfe- 
lület igencsak szűkített képességekkel rendelkezett a Win32-es 
Outlook klienshez képest (pl. feladatok, szerveroldali szabályok 
NEMkezelése). Az Exchange Server 2003-ban ez a korszak is le- 
zárul, a fejlesztőcsapat közel egy éve a legszorosabb kapcsolat- 
ban van az Office11 fejlesztőivel. Az eredmény az új Outlook 
Web Access, amely kisebb részletektől eltekintve funkcionáli- 
san azonos az új Outlook képességeivel. Bátran állíthatjuk, az 
Exchange Server 2003 OWA a Microsoft történetének legössze- 
tettebb és legprofesszionálisabb webes alkalmazása. Csak né- 
hány érdekesség, a részleteket a , Getting Started Guide" [2] ki- 
merítően tárgyalja: gyorsbillentyűk, dragg-drop, keresőmappák, 
kontextus menük, intelligens előnézet, , flagging", helyesírás-el- 
lenőrző (magyar sajnos nincs), S/MIME támogatás (!!!), csatolt 
állományok blokkolása stb. Összehasonlításképpen vessünk 
egy pillantást az új Outlook webes és windows-os változatára. 
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E Teljes szimmetria: Az Outlook 11 Win32-es és webes 
felülete 


Azt gondolom az ábrák magukért beszélnek, az Exchange Ser- 
ver 2003-ban egy átlagos felhasználó szempontjából teljesen 
mindegy, melyik klienst használja. Nem érintettük még magát 
az Outlook 11-et, mely az Office 97 kliense óta vajmi keveset 
változott. Annál inkább változtak levelezési szokásaink. Nem 
tudom, az olvasók miként vannak vele, az én postaládámba 
átlagosan öt másodpercenként érkezik egy levél. Ezt az infor- 
mációáradatot eddig csak kifinomult szerveroldali szabályok- 
kal, szűrt, csoportosított nézetekkel tudtam kezelhetővé tenni. 
Emellett érdekes jelenség, (gondolom, sokan igazolnak eb- 
ben), hogy a felgyorsult kommunikációnk ellenére, naponta 
valójában nagyon kevés, számunkra ténylegesen értékes levél 
érkezik. A sok zaj ellenére a valóságban csak ezekkel szok- 
tunk foglalkozni, s közülük is csak kevés az, amit közvetlenül 
meg tudunk válaszolni, egyszóval a fontos leveleket a felhasz- 
nálók szeretik félretenni, hogy később, ha már lehetőségük 
van megválaszolni, elővehessék. Az új Outlook 11 felhaszná- 
lói felülete épp erre van optimalizálva. A levélmegjelölés és 
csoportosítás — flagging — a felület központi szolgáltatása. Az 
új klienst használva a levelek nem ömlesztett levélhalmazként 
jelennek meg: a postaláda tartalmát a felhasználók egy sokkal 
"kifejezőbb" nézetben látják. Újdonság még a keresőmappák 
bevezetése, melynek szerveroldali komponensei már az Ex- 
change 2000-ben rendelkezésre álltak, kliensoldali integráci- 
ója azonban csak az Outlook 11-ben történt meg. A kereső- 
mappákkal tetszőleges feltételrendszer alapján — tennivalók, 
olvasatlan, nekem jött, magas prioritású stb. — ún. virtuális 
mappákat definiálhatunk, ami valójában egy folyamatosan ak- 
tualizált kiszolgálóoldali lekérdezés. Egyébként ezt eddig is 
meg tudtuk (volna) oldani kliensoldali nézetekkel, a kereső- 
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mappák azonban ennél jóval rugalmasabbak: amel- 
lett, hogy a kiszolgálóoldali támogatás miatt jóval 
gyorsabban lefut a lekérdezés, a keresőfeltételhez 
megadhatjuk, milyen hierarchikus mélységben sze- 
retnénk a lekérdezést futtatni. 

Az Outlook 11 felhasználó felületének bemutatását terjedelmi 
okok miatt most lezárjuk, adjuk most át a helyet egy másik stra- 
tégiai fontosságú témakörnek, a mobil támogatásnak. 


Mobilitás a dobozban 


Mielőtt belemélyednénk, egy történeti áttekintést teszek a mo- 
bil technológiák és az Exchange 2000 integrációja körül. Saj- 
nos Magyarországon eddig kevesen tudják, hogy az Exchange 
2000-hez a Microsoft kifejlesztett egy több szinten integrált 
mobilátjárót, a Mobile Information Server 2002-t. A MIS 2002 
három mobiltechnológiát vezetett be az Exchange 2000 szol- 
gáltatásai közé, ezek: online hozzáférés WAP 1.0-s eszközök- 
ről, kétirányú szinkronizálás a PocketPC 2002 (ActiveSync) kli- 
ensekkel, valamint egy Exchange szerveroldali szabályokra 
épülő SMS kiértesítő infrastruktúra. Az MIS az Exchange 2000 
megjelenése után két évvel került kereskedelmi forgalomba, 
célja a vállalati üzenetkezelő rendszerek , felerősítése" mobil 
technológiákkal. 


a ,mobil felfogás" a Microsoft termékfejlesztésben alapvető 
fordulatot vett. A cél ezentúl nem az, hogy újabb és újabb "mo- 
bil" termékeket fejlesszen ki a cég. Ennél lényegesen magasabb 
rendű szempont, hogy minden közeljövőben elkészülő termék 
rendelkezzen mobilképességekkel, azaz támogassa a most és 
közeljövőben megjelenő Microsoftos (PocketPC 2002, Poc- 
ketPC 2002 Phone Edition, SmartPhone 2002, Windows- 
CE.NET), valamint a külső gyártók által fejleszetett (Palm, No- 
kia stb.) nem ,MS" mobil eszközöket. Cél, hogy ezek a szol- 
gáltatások a jelenlegi (GSM, GPRS) és jövőbeli (G3) infrastruk- 
túrákon is működőképesek legyenek. Megjegyzem, a cégen 
belül, valamikor két éve, erre egy külön termékfejlesztési diví- 
zió is megszületett. Ezek alapján egyenesen következik, hogy 
az Exchange 2003-ban a mobil elérést közvetlenül a ,doboz- 
ból" kapjuk. Ahhoz, hogy postaládáinkat elérjük egy mobilte- 
lefonról, vagy szinkronizáljuk egy PocketPC-s eszközre, nincs 
szükség extra kiszolgálókra, mindez integráns része a termék- 
nek. Az integráció következménye, hogy a mobilelérés az Ex- 
change Server 2003-ban pusztán egy protokoll, az adminiszt- 
rációja a többi klienshez hasonlóan a felhasználók megfelelő 
AD attribútumainak ki- és bekapcsolásával történik. 
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E Csak semmi bonyodalom: Exchange 2003 mobilklien- 
sek konfigurálása az ADUC-ban. 





EIN 


ás/ 


Sz 


. £002 IáanIa5§ aŐUPYIK3 IIOSOIITI / 


"ayalord 


MENNI YENMNINEIT[ ENETEN 1? 


15 


" R projekt, amit valaha Titaniumnak hiutak / 


Microsoft Exchange Server 2003 


16 


A ,hogyan működik" részt terjedelmi okok miatt ismét elhagy- 
juk, ez egy későbbi cikk részeként kerül terítékre. Maguk a 
mobilszolgáltatások többé-kevésbé megegyeznek a MIS 
2002-be beépített szolgáltatásokkal — az SMS kiértesítés kivé- 
telével. Ez ugyanis kikerült ebből a verzióból. Nézzük előbb 
az online hozzáférést. Ez azt jelenti, hogy egy WAP-kliens, 
hasonlóan az OWA-hoz, valamilyen mobil infrastruktúra 
(GSM, GPRS) plusz HTTPS protokoll felett hozzáfér a postalá- 
da tartalmáhóz. Megnézheti például a leveleket, naptárbe- 
jegyzéseket, meghívót küldhet, kontaktokban és a GAL-ban 
keresgélhet, magyarul a legfontosabb Outlook , akciókat" egy 
egyszerű mobiltelefonról is elérheti. A MIS 2002-es imple- 
mentációtól ez egy fontos ponton eltér: a WAP-felületet nem 
egy ISAPI-alkalmazás, hanem a Mobile Internet Toolkit 
ASP.NET-es keretrendszere generálja. Ez az első Exchange ver- 
zió tehát, amely valamilyen formában használja a .Net run- 
time szolgáltatásait. Figyelem, ez a jelenség a következő vál- 
tozatban még tovább fokozódik! 

Az MMIT bevezetése amellett, hogy nagyságrendekkel egysze- 
rűbb implementálni, egyszerűbbé teszi az organikus módon 
fejlődő mobileszköz-gyártók újabb és újabb produktumainak 
támogatását. Az eszközadatbázis egy központi helyen tároló- 
dik, amit a Microsoft folyamatosan bővít a jövőben megjelenő 
eszközök függvényében. 


Most térjünk át a véleményem szerint legfontosabb mobilszol- 
gáltatásra, az ActiveSyncre. Aki esetleg nem ismerné, ez egy 
szerveroldali szinkronizációs szerviz, ami kétirányú szikroni- 
zálásra képes egy ActiveSync kliens és az Exchange között. A 
szinkronizálás történhet manuálisan, vagy időzítve, illetve az 
Exchange Server 2003-ban kibővül azzal a lehetőséggel, hogy 
a szerver adott pillanatokban egy speciális SMS-kiértesítő cso- 
mag formájában képes , felébreszteni", és szinkronizálásra 
késztetni a klienst. Ennek következében a felhasználók az 
ActiveSyncet használva úgy érzik, hogy ,valami" folyamato- 
san frissen tartja a mobileszköz postaládáját (,always up-to- 
date sync"). 

Most persze felmerül a kérdés, hogy milyen infrastruktúrális 
háttér szükséges egy ilyen szolgáltatás bevezetéséhez, hogyan 
értesíti ki az Exchange Server 2003 a mobileszköz SIM kártyá- 
ját, az eszköz hogyan szinkronizálja le a változásokat? (... és 
mibe kerül majd ez nekünk? — a szerk.) A folyamatot az alábbi 
ábra szemlélteti. 
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3 Az Exchange 2003 "always up-to-date" ActiveSync inf- 
rastruktúrája 


A felhasználói postaládák változásait egy speciális store event 
sink figyeli, ami egy bejövő levél esetén elkattan, és zárt SMTP 
csatornán elküld egy ,trigger"-üzenetet a vállalat által preferált 
szolgáltató felé (MS Corporate Messaging Service). A szolgálta- 
tás ezután továbbpasszolja az ,ébresztő"-üzenetet az SMS-köz- 
pontba, ahonnan az lejut a felhasználó egységére (pl. PocketPC 
Phone Edition vagy SmartPhone). Amennyiben az ,alszik" 
(stand-by mode), felébred és elindítja az ActiveSync klienst, ami 
— HTTPS csatornán történő hitelesítés után — felkéri a szervert, 
hogy fésülje össze és küldje le a kliensoldalon frissítésre szoru- 
ló változásokat (levelek, naptárbejegyzések, kontaktok). 
Egyelőre most ennyit az Exchange Server 2003 mobilszolgálta- 
tásairól, most nézzük meg milyen újdonságok könnyítik meg 
az üzenetkezelő infrastruktúrák adminisztrátorainak közel sem 
zökkenőmentes életét! 


Rendszerfelügyelet: irány a Windows Server 2003! 


Helyszűke miatt sajnos ebből is csak csemegézni van lehetősé- 
gem. Gondolom, nem mondok újat, hogy ezen a területen a fő 
fejlesztési cél a Windows Server 2003 új szolgáltatásainak 
(Cross Forest Kerberos Authentication, Shadow Copy, Cluster 
Service) minél teljesebb körű kihasználása, és néhány tipikus, 
az adminisztrátorok életét megnehezítő feladat simulékonnyá 
tétele volt (pl. ,brick level restore", Mailbox Recovery Center, 
Message Tracking). Érdekes még, hogy a fentiek mellett van né- 
hány, csak az Exchange Server 2003-ban megjelenő technoló- 
gia. Zárásként két kedvencemet említem meg ezek közül: 


H Az első egy új DL típus, a Ouery Based DL objektum, 
ami tulajdonképpen egy felhasználói objektumokat 
előállító LDAP lekérdezés. Segítségével a DL hierarchi- 
ákat nem kézzel kell karbantartanunk, elég csak kere- 
sőfeltételeket megadnunk, amit az Exchange transzport 
dinamikusan lefuttat. 

A A másikodik kedvencem orvosság egy nagyon is valós 
problémára, szaknyelven szólva a ,szpemmelésre". Ez 
ugyan eddig is benne volt az Outlook kliensben, ám 
sajnos kevesen használták. Az Exchange Server 2003- 
ban ezentúl beépített támogatást kapunk a spamforrá- 
sok szerveroldali adminisztrálására, megadhatunk pél- 
dául külső, ún ,black-hole" szolgáltatókat, ahonnan fo- 
lyamatosan letölthetjük a ,hulladéklevél gyártók" listá- 
ját, hasonlóképpen ahhoz, ahogy egy antivírus szerviz 
frissíti a vírusminta adatbázisát az Internetről. 


2003. január 27, 
Seattle, WA United States 


Bátorfi Zsolt 
zbatorfiomicrosoft.com 


MELL! 

(11 http://www.microsoft.com/exchange/evaluation/ti/default.asp. 

(2] http://download.microsoft.com/download/e/d/f/edfdeb7f- 
289d-4elb-8f2e-663bBdea68db/etb2gsg pdí.exe 





ficrosoít Exchange 2000 


Nyilvános mappák replikációja 


Kis szünet után folytatjuk az Exchange 2000-ről szóló sorozatot. Ebben a részben a 
nyilvános mappák replikációjával ismerkedhet meg a kedves olvasó. Megvizsgáljuk, mi áll a nyilvános 
mappák replikációjának hátterében, részletesen foglalkozunk a replikáció folyamatával, a konfliktus- 


kezeléssel, valamint a hibaelhárítással is. 


A legtöbb helyen, ahol Exchange-kiszolgálók üzemelnek, a 
nyilvános mappák adta lehetőségeket is kihasználják. Ahol 
több kiszolgáló működik, ott máris jelen van a nyilvános map- 
pák replikációja — ha akarjuk, ha nem. 

Miért is érdemes a nyilvános mappákat több példányban tá- 
rolni? 

A nyilvános mappák replikációjával magasabb szintű hibatű- 
rést és rendelkezésreállást tudunk biztosítani. Több telephely 
esetén a WAN-kapcsolatokat kevésbé terheljük, ha a nyilvános 
mappákat minden telephelyre lemásoljuk, mintha egy közpon- 
ti helyen próbálnánk őket elérni távoli telephelyekről. Az ügy- 
felek elsősorban a saját telephelyükön levő Exchange kiszolgá- 
lón található nyilvános mappákhoz fordulnak, így mindenki a 
legközelebbi forrásból olvas, és majd a háttérben történik adat- 
csere, amely időzíthető. 


Ugyanakkor hátrányai is vannak az elosztott rendszernek, hi- 
szen a változások nem jelennek meg azonnal mindenütt, bi- 
zony a replikáció időbe telik. Ha túl hosszú az átmeneti idő, 
gyakran konfliktusok alakulhatnak ki a tartalmat illetően, ame- 
lyeket kezelni kell, méghozzá manuálisan. A replikáció is nö- 
veli a levélforgalmat a kiszolgálók között, hiszen minden vál- 
tozás levél formájában utazik a kiszolgálók között. Az egyes 
nyilvános mappákra a többszörözés beállítása a rendszergaz- 
dák feladata. Fontos tudni, hogy a legfelső nyilvános mappák- 
ra kiadott replikációs beállítás öröklődik a később létrehozott 
könyvtárakra és objektumokra, de a már meglevőkre nem, 
azokra minden esetben le kell terjeszteni a beállításokat. 
Lehetőség van nemcsak egy Exchange szervezeten belül, ha- 
nem különböző szervezetek közt is a nyilvános mappák ter- 
jesztésére. Ehhez az Exchange 2000 telepítő CD-n elérhető se- 
gédprogramokat lehet használni (a SupportNExchsyncW386 
könyvtárból). Ebben cikkben csak a szervezeten belüli nyilvá- 
nos mappa replikációjával foglalkozunk. 


Nyilvános mappák elérése 

Hogyan dönti el az ügyfélprogram — mondjuk az Outlook -, 
hogy melyik kiszolgálóhoz forduljon, amikor egy nyilvános 
mappában levő levélre van szüksége a felhasználónak? 
Lássuk csak: Júzer Jolánnak az alábbi képen látható fontos.doc 
fájlt kellene elérnie a közös mappából. 









.PF referrals" 
engedélyezve 


, PF referrals" 
engedélyezve 


Los Angeles j 


2 Júzer Jolán és a fontos.doc 


Júzer Jolán postaládája XCH1 kiszolgálón található, Jolán eh- 
hez kapcsolódik, amikor Outlookot használ. Ha a fontos.doc 
fájl is megtalálható a kiszolgálón, ahol Jolán postaládája van, 
akkor Jolán máris célba ért, az Information Store rendelkezés- 
re bocsátja a fontos.doc-ot. Ha ugyanez a fájl az azonos útvá- 
lasztó csoportban levő másik kiszolgálón található, Jolán azt a 
fájlt is el tudja érni. Ha azonban a fontos.doc egy másik útvá- 
lasztó csoportban, másik telephelyen található, csak akkor 
kaphatja meg Jolán az áhított fájlt, ha a , Public Folder Reffer- 
rals" - hívhatjuk PF utalásnak - nincs letiltva az útválasztó cso- 
portok közti csatolón. Exchange 2000-ben a PF utalás teszi le- 
hetővé, hogy a nyilvános mappák tartalma útválasztó csopor- 
tok közt is elérhető legyen a felhasználók számára. 

A ,PF referrals" alapértelmezésben engedélyezve van az útvá- 
lasztócsoportok közt, a csoportok közti csatolók (Rrouting 
Group Connector, vagy SMTP connector) tulajdonságai között 
lehet letiltani a beállítást. 


ós] 
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CAS azaszzááty aa 2]xI 





Address Space l Connected Routing Groups l Delivery Restrictions l 
Content Restiictions 1. Delivery Options ]. Advanced ] Detais ) Security ] 


General 
úg Belso levelezes 


C UseDNS to route to each address space on this connector 
("Forward all mail through this connector to the following smart hosts 


ferde. nyitraders.msít 


Local bridgeheads: 








LONDON 


Default SMTP Virtual Server 


Add... Remove 








[ok TT. cmd [/ 65 [/ Hop ] 


E , PF referrals" tiltása/engedélyezése 


Régebbi motorosok az Exchange előző verzióiban, mint ,PF 
Affinity" találkozhattak ezzel a beállítással. Az előző verziók- 
tól eltérően Exchange 2000 esetén a ,PF referrals" beállítás 
tranzitív. Tehát ha a szervezetben legalább három útválasztó 
csoport van, mondjuk egy központi és két külön telephely, 
ahogy a képen is az egyik Los Angeles a másik Moszkva, vala- 
mint a PF utalás nincs letiltva, Júzer Jolán Moszkvából képes 
lesz elérni olyan nyilvános mappák tartalmát is, amelyek tulaj- 
donképp Los Angelesben vannak. 


Központ 











, PF referrals" 
engedélyezve 


ü. 
z 
g 


2 0 Tranzitív , PF referrals" 


a PF referrals" 
engedélyezve 


v 
4 
[3 


Miért van erre szükség? Mikor Júzer Jolán kapcsolódik a nyil- 
vános mappákhoz az Outlookból, az alapértelmezett jogosult- 
ságok mellett az egész nyilvános mappa struktúrát láthatja, 
mert a hierarchia automatikusan replikálódik. A tartalom azon- 
ban nem. A nyilvános mappa utalások segítségével tudják a fel- 
használók kéréseit a távolabbi helyekről is kielégíteni a kiszol- 
gálók. 

Persze ha ez nem szükséges, az a dolga a rendszergazdának, 
hogy az előző képen is látható jelölőnégyzetet bejelöli az út- 
választó csoportok közti csatolón. Ilyenkor Jolán csak a hely- 
ben levő mappák tartalmához fog hozzáférni. 


Mappák 


Az Exchange 2000-ben minden nyilvános mappa-példány 
egyenrangú. Nincs többé , Home Server", helyette úgynevezett 
multimaster replikációra váltottak Redmondban. 

Az előbb már említettem, hogy a nyilvános mappák hierarchi- 
ája (könyvtárszerkezete) és a tartalom külön replikálódik. Az 
elsőként létrejött nyilvános mappa hierarchia — amit úgy is hí- 
vunk: MAPI hierarchia-, automatikusan az egész szervezetben 
replikálódik. A külön létrehozott nyilvános mappa-struktúrá- 
kat, mind a tartalmat, mind pedig a hierarchiát , kézzel" kell 
replikálni, vagyis beállítani a replikációt. 

A replikáció folyamata nem túl hatékony módszerrel, levelek 
formájában történik. Az Information Store egy része, a ,Public 
Folder Replication Agent" — röviden PFRA felelős a replikáci- 
ós üzenetek küldéséért és a kapott üzenetek feldolgozásáért. 


A replikáció beállítása 

A replikáció néhány beállítását adatbázisszinten kell megejte- 
ni. Beállíthatjuk például, hogy az adott adatbázis tartalma mi- 
kor másolódhat. Akkor lehet erre szükség, ha lassú WAN-on 
keresztül szeretnénk replikációt beállítani. 


Ezen kívül beállíthatjuk azt az intervallumot percekben, ami- 
kor replikáció elindulhat — ez alapértelmezésben 15 perc. 


kára eger Teng Ke 2lx] 








FulkTextindexing — ] — Detais ] — Policies  ] Security  ] 

General] Database Replication ] Limit] 
Replication interval: 
TETÉZTE 7]. Cwsiorize. ] 
Limits 

Replication interval for always (minutes): 15 

Replication message size limit (KB): 300 


Restore Defaults I 





5 A replikáció adatbázisszintű beállításai 


Amikor nyilvános mappa-replikációt tervezünk, érdemes oda- 
figyelni a replikációs levél méretének megválasztására. Ez 
ugyanis nem a levél méretének maximumát, hanem a minimu- 
mát adja meg! Vagyis az itt megadott méretig a PFRA össze- 
gyűjtögeti a változásértesítőket, és ha több belefér 300KB-ba, 
többet küld egyszerre. Ha viszont 10MB-os fájl változik a nyil- 
vános mappákban, a PRFA a változásértesítőbe belerakja az 
egész fájlt, ráadásul egy replikációs üzenetben fog eljutni a 
többi kiszolgálóhoz a nagyméretű állomány! Ez az eljárás csu- 
pán akkor hatékony, ha sok de nem nagy állományt kell repli- 
kálni, ilyenkor nem nőnek nagyra a replikációs üzenetek. A 
PRFA nem tudja tördelni a fájlokat, ami változik, azt egy az 
egyben küldi szét a többi kiszolgálónak. 

Kicsit javíthatunk ezen az állapoton, ha meghatározzuk az ele- 
mek maximális méretét a nyilvános mappákban, vagy ha a rep- 
likációt úgy időzítjük, hogy a nagy replikációs levelek ne aka- 
dályozzák a normális működést. Ha nem figyelünk, előfordul- 
hat, hogy az átlagos levelezés nagyon lassú lesz, mert épp a 
nyilvános mappák replikálódnak, lefoglalva a sávszélességet és 
a kiszolgálók erőforrásait. 


Mappaszintű beállítások 


Az egyes nyilvános mappákra külön-külön is be lehet állítani 
néhány dolgot a replikációval kapcsolatosan, illetve van olyan, 
amit csak és kizárólag a nyilvános mappák szintjén tudunk be- 
állítani. A beállítások minden esetben az egyes nyilvános map- 
pák tulajdonságai közt a Replication tulajdonságlapon találha- 
tók, ahogy az alábbi képen is látható. 

A legfontosabb talán a replikációs partnerek beállítása. Mint 
már említettem, Exchange 2000 esetén a partnerek egyenran- 
gúak, nincs többé , Home Server" tulajdonság. Akár minden 
nyilvános mappára külön időzíthetjük a replikációt az alábbi 
tulajdonságlapon látható , Customize" gomb mögött, de alap- 
beállításként mindig az adatbázis egészére beállított időzítéssel 
jut el a tartalom a többi kiszolgálóra. 

Ezen kívül állíthatjuk a replikációs üzenetek sürgősségét , illet- 
ve megnézhetjük a replikáció állapotát is (lásd később). Most 
nézzük a beállítások öröklődését, illetve terjesztését! 


DEEIZZTZT TEN NSEEENTNTT 
General Replication ] Límits ] Details ) Permissions ] 
Replicate content to these public stores: 


212 








Add... ] Remove. I 
Public folder replication intervak 
[Use public store schedule -] Customize... I 
Replication message received: Details... 


Replication message priority: 
[Nat Urgent r] 





Cancel I Apply I Help ] 


5 Nyilvános mappák replikációs beállításai 








A beállításokat nem öröklik automatikusan a szülőmappák lé- 
tező gyermekei. Le kell terjeszteni az összes meglevő alsóbb 
mappára, ha ugyanazokat a replikációs beállításokat szeret- 
nénk látni mindenütt. A létrejövő alsóbb mappák születéskor 
ugyan öröklik a szülőkönyvtár tulajdonságait, de ha ez később 
megváltozik, az már csak a kiválasztott mappára lesz érvényes, 
automatikusan nem öröklődik. 


a 


- 


te h.net SET RÜVT w i 





a 


1 A PF beállítások terjesztése 


A beállítások terjesztése (propagálása) jól el van dugva a me- 
nük közt, de a fenti képen jól látható, honnan lehet előhúzni. 
Külön lehet a nyilvános mappák különböző beállításait terjesz- 
teni. A replikációnál maradva: külön lehet a replikációban 
részt vevő kiszolgálók beállítását örökölni — ez a képen is lát- 
ható , Replicas", külön a replikációs üzenetek sürgősségét, és 
külön az időzítést is. Persze együtt is lehet terjeszteni a beállí- 
tásokat, ha mindegyik jelölőnégyzetbe pipát rakunk, ahogy az 
alábbi képen is látszik. 


Propagate Folder Settings 


Select the property of this folder to apply to all sub-folders. 
Properties: 

( Administrative rights 

E Age limits 
(CT Deleted item retention time 


E Folder rights 
EJ Keep per user read/unread state 





2 






[E Replication message priority 
B Replication schedule 
(CT Storage limits 


box ] crea ] 


a A replikációs beállítások terjesztése egy menetben 


A replikáció folyamata 

Érdemes kitérni a replikáció folyamatára, hogy megértsük pél- 
dául az állapotjelzők működését. 

Azt már említettem, hogy a replikációért a PRFA vagyis a ,Pub- 
lic Folder Replication Agent" felelős. A PRFA nem egy külön 
szolgáltatás, hanem az Information Store része. 

A PRFA feladatai a következők: 


AA A nyilvános mappa-példányok nyilvántartása 

A A replikációs üzenetek képzése és címzése 

A A változások figyelése, a beérkezett replikációs üzene- 
tek feldolgozása 


De akkor ki küldi a replikációs üzeneteket? Az SMTP kiszolgá- 
ló! A replikációs üzenetek winmail.dat bináris mellékletek for- 
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májában úgynevezett TNEF (Transport-neutral En- 
capsulation Format) formában utaznak a kiszolgálók 
] közt. 
A változások követése állapotinformációk (Message 
State Information) alapján történik. Az állapotinfor- 
mációknak három alkotója van. 


1. Változási szám (change number) -— egy IS-en belül a válto- 
zásoknak megfelelően növekvő szám. Egyik része állandó 
— ez az IS-t azonosító GUID-, a másik része pedig a válto- 
záskor mindig növekvő számláló. 

2. változási lista (predecessor change list) — minden fájlhoz 
tartozó lista, amely felsorolja az összes IS-t, amelyben az 
elem változott (mellérendelve rögtön a változási számot is). 
Valahogy így nézhet ki: 


Moszkva (500 
— Központ NN era 450 . se ci 
c Los Angeles jN 800 Ni . 
. Központ 9 
(Moszkva 3005tb 


3. Időbélyeg — a létrehozás vagy változás pontos ideje. 


A PRFA az állapotinformációk alapján dönti el, hogy a kapott 
példány frissebb-e, mint ami helyben megtalálható. 


Nézzük a folyamatot, amikor változások replikálódnak a ki- 
szolgálók közt: 


Fontos.doc 


Központ 






Fontos.doc MNOSrTS 


LA — 400 
54548 
Los Angeles 


Id Replikáció előtti kiindulási állapot, amikor minden ki- 
szolgálón ugyanaz a példány szerepel 





1. Tovaris Júzer Jolán Moszkvában megváltoztatja a nyilvános 
mappában lévő fontos.doc-ot. 

2. A Moszkvában levő PRFA megváltoztatja a fontos.doc álla- 
potinformációit, tehát növeli a változásszámot, frissíti a 
változáslistát és az időbélyeget is. 





Fontos.doc ma 


Központ 








Fontos.doc 
KrT3 F 


B Friss állapotinformáció 


3. APRFA létrehozza a replikációs üzenetet, benne a friss vál- 
tozásértesítő és maga a megváltozott fontos.doc szerepel. 

4. A PRFA a replikációs beállításoknak megfelelően megcím- 
zi a replikációs üzenetet. 

5. Az SMTP kiszolgáló szétküldi a leveleket Los Angelesbe és 
a Központba is. 

6. A fogadó PRFA — mondjuk a Központban - kibontja a rep- 
likációs üzenetet. Ha a kapott állapotinformációban levő 
változási listában szerepel a helyben levő elem változás- 
száma, úgy érzi, hogy bizony ez egy frissebb elem, és a 
helyben levő fontos.doc-ot lecseréli a kapott fontos.doc-ra, 
és az állapotinformációkat is írissíti. 


(dlulesáe ua 


Info. 
VSz-Központ: 500. 
Központ — 500 
Moszkva — 300 








LA — 400 
2002. 10.24. 5:45:48 


Központ 


kelülsáeles 


Fontos.doc 


Los Angeles 





DO 


- Melyik példány a frissebb? 


Jelen esetben a Központba érkező fontos.doc-hoz tartozó vál- 
tozáslistában szerepel a Központban, helyben levő változási 
szám (Központ — 500) ezért a központi PRFA le fogja cserélni 
a helyben levő fontos.doc-ot a kapottra, majd frissíti az állapot- 
információt. Ugyanez történik Los Angelesben is. 


A replikáció állapotát a System Managerrel lehet nézegetni. 
(Sajnos azonban a replikáció működése miatt nem mindig a 
valódi állapotot láthatjuk.) 


A replikáció állapotára kétféle jelzőt használ az Exchange: 

A In Sync - amikor azt gondoljuk, szinkronban vannak a 
példányok. (Pedig ez csak azt jelenti, hogy az utolsó 
változásértesítőket a PRFA elkészítette, és az SMTP ki- 
szolgálónak lepasszolta, és azóta a helybeli példány 
nem változott. Nem tudhatja a PRFA, hogy a változá- 


sok valóban megérkeztek-e a többi kiszolgálóhoz! 
Nincs visszajelzés a replikációról.) 

TA Local Modified —a helyben levő példány változott, de a 
PRFA még nem kürtölte szét a változást. 


Viszonylag könnyen előállhat olyan állapot, hogy a System 
Managerben azt látjuk, szinkronban vannak a nyilvános map- 
pák példányai, de valójában mégsem. Ilyenkor leginkább a ki- 
szolgálók közti üzenetforgalmazást kell ellenőrizni — tehát az 
SMTP kiszolgálót. 


A rendszermappák replikációja 


Vannak olyan nyilvános mappák, amelyek a hierarchiában 
nem látszanak, de a tartalmuk igen fontos. A System Manager- 
ben láthatók ezek, ha a Folders konténerben a Public Folders 
hierarchián állva a gyorsmenüből (jobb klikk) a , View System 
Folders" parancsot választjuk. A következő rendszermappákat 
találhatjuk itt: 


H Events Root: — az Exchange 5.5 kompatibilis scripteket 
tartalmazza 

HI EFORMS REGISTRY - Outlookkal használható sablo- 

nok tárolója az ,Organization Froms Library" tartalma 

OFFLINE ADDRESS BOOK - helyi címlisták tárolója 

schedule- free/busy — a felhasználók és erőforrások el- 

foglaltsági információi találhatók itt 

Schema - nyilvános mappák és tartalmuk tulajdonsá- 

gainak leírása található ebben a mappában 

HA StoreEvents — Exchange 2000 formátumú scriptek. 


B BB 


A sok rendszermappa közül a Offline Address Bookot és a 
Free/Busy mappát emelném ki. Mindkét mappa csak az admi- 
nisztratív csoportban elsőként létrehozott kiszolgálón található 
meg, viszont szükség lehet rá bármelyik kiszolgálón. Nem ide- 
ális, ha csak egyetlen kiszolgálón tároljuk ezeket, ha ez a ki- 
szolgáló épp nem működik: az Outlookot használók hibaüze- 
neteket kapnak, amikor egy találkozót próbálnak összehozni, 
és ehhez megfelelő időpontot keresnek a többiek elfoglaltsága 
alapján. Mind a két rendszermappa tartalmát érdemes minden 
kiszolgálóra elterjeszteni. Ez minden esetben a rendszergazdák 
dolga, nem történik meg automatikusan! Ha több adminisztra- 
tív csoport van egy szervezeten belül, érdemes keresztberepli- 
kálni ezen mappák tartalmát, hogy mindenkor elérhető legyen 
a címlista és az elfoglaltságok is. 


A konfliktusok kezelése 


Mi a helyzet, ha a változások nem jutnak el egyik kiszolgáló- 

ról a másikra, vagyis nincs benne a kapott változási listában a 

helyben levő példány utolsó változási száma? Példánkhoz 

visszatérve két dolog lehetséges: 

1. A Központban is megváltoztatta valaki a fontos.doc-ot és a 
változások még nem replikálódtak 

2. Nem jutottak el Moszkvába a Központból a változásértesí- 
tők miközben a fontos.doc többször is változott. 

Az első esetben manuális konfliktuskezelés szükséges, a máso- 
dikban pedig elindul automatikusan a , backfill" — vagy hív- 
juk csak pótlásnak. 


A változási listák hivatottak megmondani, hogy frissebb-e a ka- 
pott példány a meglevőnél vagy sem. A PRFA ezt úgy próbálja 
eldönteni, hogy a kapott változáslistában megkeresi a helyben 
levő példány utolsó változási számát. Ha megtalálja, biztos le- 
het benne, hogy a kapott példány frissebb, mint a helyben le- 


vő. Konfliktushelyzet akkor alakul ki, ha ugyanazt a 
fájlt közel azonos időpontban két helyen is módosí- 
tották, és ezek a változások mennek szembe egymás- 
sal. Mindegyik úgy érzi, ő a legírissebb példány, de 
egyik PRFA sem fogadja be a kapott fájlt, mert nem 
találja a legírissebb változási számot a kapott változási listá- 
ban, hisz az még nem érhetett oda. 

Ilyen esetben valahogy el kell dönteni, melyik a megfelelő pél- 
dány. Egyik PRFA sem tudja eldönteni, ehelyett a nyilvános 
mappa kapcsolattartójához és a módosítást végző személyek- 
nek (Contact) elküldi mind a két példányt. A konfliktuskezelés 
manuális. Az egyik felhasználó dönt az érvényes példányról — 
vagy nem dönt, és a konfliktus fennmarad. 


Nyilvános mappák mozgatása 

Ha mondjuk Moszkvából a Központba szeretnénk mozgatni 
bizonyos nyilvános mappákat és tartalmukat, tulajdonképp 
ugyanúgy a replikációt kell elindítani először, mintha csak ter- 
jeszteni szeretnénk a tartalmat. 

Sikeres replikáció után pedig a példányokat tartalmazó listából 
egyszerűen el kell távolítani a moszkvai kiszolgálót és kész. 
Igazából nem szükséges megvárni a replikáció befejeződését, 
mert csak a replikáció befejeztével fogja az IS letörölni a nem 
kívánt példányt, bár ilyenkor a replikáció alatt nem érhető el a 
nyilvános mappák tartalma. Mégis érdemes először replikálni, 
és csak aztán kivenni a kiszolgálót a listából, mert ez (talán) 
biztonságosabb. Replikáció után véletlenül se töröljük a kiszol- 
gálóról a nyilvános mappát, hisz a törlés is egy változás, ami 
replikálódni fog a többi példányhoz. Nyilvános mappa mozga- 
tásakor a kiszolgálók listáját változtatjuk a nyilvános mappa 
replikációs tulajdonságlapján! 

Amikor törlünk egy nyilvános mappát, az IS törli a tartalmát, 
majd a PRFA változásértesítőt küld a többi kiszolgálónak, és 
minden kiszolgáló maga törli le a helyi példányát. 


A pótlás (Backfill) folyamata 


A kiszolgálók nem tudják hogy az általuk küldött replikációs 
üzenetek valójában megérkeztek-e a többi kiszolgálóhoz, 
nincs semmilyen visszacsatolás. Amint a PRFA átadta az SMTP- 
nek az üzeneteket, azonnal In Sync állapotba teszi a nyilvános 
mappa állapotát. 
A vakság miatt akkor is mennek a nyilvános mappákról állapot- 
üzenetek (naponta), ha nem változott semmi. Ha a helyben le- 
vő változási lista tartalmazza a kapott változási számot, ez azt 
jelenti, tényleg szinkronban van a nyilvános mappák tartalma. 
Ha a kapott változási szám nem szerepel helyben, a küldőhöz 
visszamegy egy kérés, hogy pótolni kellene az újabb fájlokat. 
Az utolsó változási számok alapján a kiszolgálók tartalma 
szinkronizálódik. 
A pótlási folyamat akkor indulhat el, 

AA ha egy kiszolgálót régebbi mentésből állítottunk vissza, 

JA ha hosszabb ideig nem volt hálózati kapcsolat a kiszol- 

gálók között 
A ha elvesztek a replikációs üzenetek az éterben. 
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Változás értesít 


E Utólagos feltöltés folyamata 


Mondjuk Jolán Moszkvában megváltoztatja a fontos.doc fájlt. 

1. A moszkvai kiszolgáló változás-értesítőt küld minden ki- 
szolgálóhoz, de ez Los Angelesbe nem jut el, persze erről 
Moszkva mit sem tud. 

2. A Központig eljut a változás, idővel a központi kiszolgáló 
állapotértesítőt küld szét a fontos.doc-ról akkor is, ha nem 
változott. 

3. Moszkvában minden rendben, de LA észreveszi, hogy a 
központban frissebb verzió van, mint nála, ezért kéri a pót- 
lást. 

4. A központi kiszolgáló elküldi a frissebb fájlt. 
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REMEK, AKKOR TE BIZTO- 
SAN KÉPES LESZEL DÉLU- 
TÁNRA BEGÉPELNI A SKÚL 
SZERVERBE EZT A 

(2600 TÉTELES LISTÁT! 


MELYIKŐTÖK 
IS AZ MCDBA? 


De mi van, ha Jolán véletlenül letörli a fontos.doc-ot a moszk- 
vai kiszolgálóról? A rendszergarázda fogja, és visszaállítja a 
nyilvános mappa-adatbázist a tegnapi mentésből. Egy idő 
után a mentés óta változott fájlok replikálódnak a visszaállított 
kiszolgálóra, mert a backfill automatikusan beindul. Ennek 
eredményeképp a fontos.doc is egyszer csak ismét eltűnik a 
nyilvános mappából. Mit lehet tenni ez ellen? Például nem az 
éles kiszolgálóra állítjuk vissza a nyilvános mappa adatbázist, 
hanem egy elkülönített masinára, majd onnan exportáljuk pst- 
be, és importáljuk az éles kiszolgálóra. Kicsit körülményes, de 
működik. 


Folytatjuk... 


Dorner Csilla 
dorner.csillaonetacademia.net 
A szerző a NetAcademia oktatója, MCSE 
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Az Exchange 2000 és a SharePoint Portal Server külön-külön is rengeteg előnnyel és funkcióval ren- 
delkezik. Ebben a cikkben azt mutatom be, hogy milyen lehetőségek tárulnak elénk, ha a két szervert 


,Összeházasítjuk". 


Az Exchange2000 Server és a Web Storage System 


Az elmúlt évben néhány cikken keresztül részletesen kitértem 
arra, hogy a WSS adatai hogyan, milyen módszerekkel érhetők 
el saját alkalmazásunkból. Ezeket most nem kívánom újra 
megismételni, azonban azon Olvasók kedvéért, akik az emlí- 
tett cikkeket nem olvasták és nem járatosak a témában, néhány 
szóban bemutatnám, miről is van szó. 

A WSS (Web Storage System) az Exchange2000 Server (és a 
SharePoint Portal Server) adattárolási mechanizmusa, amely 
sokoldalú hozzáférést biztosít az adatokhoz (HTTP, SMTP, 
IMAP4, POP3, stb.). Felépítése hierarchikus: a különböző fáj- 
lok, dokumentumok mappákba szervezhetők, s ezek a mappák 
(folderek) tetszőleges mélységig rekurzívan egymásba ágyaz- 
hatók. 

A kétféle store-típus közül a Mailbox store olyan adatbázis, 
amelynek mappáihoz és dokumentumaihoz egyetlen felhasz- 
náló, a tulajdonos fér hozzá. E-maileket, hozzájuk csatolt állo- 
mányokat, mappákat, dokumentumokat stb. tárolhatunk itt. 
Természetesen minden felhasználóhoz egyéni Mailbox store 
rendelhető. 

A Public store legfőképpen abban különbözik a Mailbox store- 
tól, hogy nem egyetlen felhasználó kizárólagos tulajdona, meg- 
osztottan többen is hozzáférhetnek, használhatják, rendelkezhet- 
nek tartalma fölött — persze a megfelelő jogosultságok alapján. 


ús . 
Store Hello bela.emi 
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E A Web Storage System felépítése 


A SharePoint Portal Server és a Web Storage System 


A SharePoint Portal Server hasonló módon tárolja adatait, ter- 
mészetesen más céllal: itt nem a levelezésen és az ahhoz tar- 
tozó funkciókon, hanem a dokumentumkezelésen van a hang- 
súly. 





Addig beszélünk dokumentumkezelésről, amíg a végfelhasz- 
náló a Word, Excel, Access és egyéb dokumentumait szerkesz- 
ti a számítógépén. A tevékenység kapcsán sok egyéb mellett 
olyan kérdések merülnek fel, mint a dokumentumoknak köz- 
ponti tárba történő mentése, ottani tárolása és nyilvántartása, a 
felhasználó által onnan való kikölcsönzése és ezen idő alatt 
mások számára való zárolása, a dokumentum verzióinak keze- 
lése, a dokumentumnak a külvilág számára történő publikáci- 
ójának támogatása, vagy a jóváhagyási procedúra. E folyama- 
tok közben a dokumentum tartalma megváltozhat. 

A SharePoint Portal Server (SPPS) e funkciókat hivatott megva- 
lósítani, háttérben a WSS-sel, ahol az elsődleges adattárolás és 
-feldolgozás történik. 

SPPS-ben az információk, adatok, dokumentumok tárolására a 
tartalomforrások (content source) szolgálnak. Kliensoldalon 
mindezt egy URL segítségével érhetjük el. Tartalomforrásként 
nemcsak a WSS mappái, hanem egyéb típusú helyek is meg- 
adhatók: 

weboldalak 

megosztott file-ok 

Exchange2000 Public Folderek 

Exchange 5.5 Public Folderek 

Lotus Notes adatbázisok 

SPPS munkaállomások (akár távoliak is). 

(Amennyiben olyan tartalomforrás-típust szeretnénk elérni, ame- 
lyet nem támogat a SharePoint Portal Server, az interfészek kiter- 
jeszthetők, azaz saját protokollkezelőket is létrehozhatunk.) 


BBBBBB 


Az SPPS adatai különböző módszerekkel érhetők el. A fenti for- 
rások közül most azt szeretném bemutatni, hogy egy Exchan- 
ge2000 mappa hogyan indexelhető be, illetve kezelhető az 
SPPS keresőmotorjával. A kérést tehát az SPPS kapja klien- 
sünktől, és ő az indexei alapján küldi a választ — de az Exchan- 
ge2000 Web Storage System alapján. 


a 
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Lássuk tehát, mi mindent kell beállítanunk és elvégez- 
nünk a fenti architektúra megvalósítása érdekében. 
Először is hozzunk létre egy munkaállomást (work- 
space) az SPPS-en, és adjunk neki egy találó, fantázi- 
adús nevet, legyen például Agnes. Ezt az SPPS admi- 
nisztrációs eszközével tehetjük meg (Start 2 Programs 2 Ad- 
ministrative Tools 2 SharePoint Portal Server Administration). 
A bal oldali ablakrészben a fából válasszuk ki a kiszolgálónkat, 
majd jobb egérgombbal rákattintva a New -2 Workspace me- 
nüpontot válasszuk ki, és máris indul a varázsló. 
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E Új workspace létrehozása SharePoint Portal Serveren 


Következő lépésként nyissuk meg ezt a munkaállomást (My 
Computer 2 Web Folders). Ezzel a SharePoint Portal Server 
már alkalmas arra, hogy rajta különböző tartalomforrásokat 
hozzunk létre. 


Ahhoz, hogy egy Exchange2000 WSS mappa (vagy bármely 
más típusú tartalomforrás) tartalmát elérhessük SPPS-en keresz- 
tül, annak tartalmát be kell indexelni valamely munkaállomás 
alá (ennek küldjük majd később a hozzáférési kéréseket a kli- 
enstől). Ennek érdekében a megnyitott munkaállomás Manage- 
menNContent Sources ágát kifejtve klikkeljünk az 0 ikonra 
(lásd az alábbi ábrá. 

Ekkor egy varázsló indul el, amelynek segítségével különböző 
tartalomforrásokat tehetünk elérhetővé. Első lépésként ennek 
típusát kell kiválasztani, azaz a fent említett lista valamely ele- 
mét. Válasszuk ki az , Exchange 2000 Server public folders" 
opciót. Második lépésként az elérendő Web Store mappa URL- 
jét kell megadni (legyen ez például http: / /myExchan- 
ge2000server/public tree/myfolder/. Adjuk meg, 
hogy a mappát milyen mélységig szeretnénk indexelni: csak az 
adott mappát (Only this folder) vagy minden almappájával 
együtt (This folder and all subfolders). Végül adjunk egy nevet 
az indexmappának (pl. myXchiNdex), majd indítsuk el az in- 
dexelést. Ez néhány percet biztosan igénybe vesz, közben nyu- 
godtan olvassuk tovább ezt a cikket . 
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D Tartalomforrás hozzáadása 


Ha kész az indexmappánk, azon jobb egérkattintással további 
dolgokat állíthatunk be. Ezek közül az egyik legfontosabb le- 
hetőség a frissítés ütemezése, melynek két típusa létezik. A tel- 
jes frissítés minden alkalommal a teljes Exchange-mappán (és 
a beállításoknak megfelelően annak összes almappáján) végig- 
megy, és annak minden elemét teljes egészében újraindexeli 
az SPPS-en, függetlenül attól, hogy azon történt-e változás a 
legutóbbi frissítés óta. Ezzel szemben inkrementális frissítés 
esetén csak a módosítások, illetve az új dokumentumok kerül- 
nek át az indexbe, ezáltal csökkentve egyrészt az adatforgal- 
mat, másrészt a frissítésre fordítandó időt is. 

Az adaptív írissítés az inkrementális frissítés egyik válfaja, 
amely különböző statisztikákat, heurisztikákat használ a haté- 
konyság növelésének érdekében. Rögzíti például, hogy milyen 
gyakran változik a tartalom, és ennek függvényében végzi a 
frissítéseket. 

Az utolsó, leghatékonyabb módszer az értesítő frissítés, amikor 
is változás esetén a tartalomforrás értesítést küld az SPPS ki- 
szolgáló indexének. Ezen esemény hatására indul el a frissítés 
a tartalomforrás indexén. Az SPPS ezt használja alapértelme- 
zett beállításként, hátránya viszont, hogy csak az SPPS saját 
store-jában illetve NTFS fájlrendszerben elhelyezett dokumen- 
tumokra használható. 


A írissítés típusán kívül az időzítést is beállíthatjuk (milyen 

időközönként induljon automatikusan az index frissítése), illet- 

ve különböző szabályokat is megadhatunk az indexek létreho- 
zásához. Háromféle szabálytípust különböztethetünk meg: 

1. ,Site path" szabályok: az indexbe felvehető dokumentu- 
mok számának korlátozására (maximum hány dokumen- 
tum szerepelhet az indexben). 

2. ,Mapping" szabályok: Hogyan jelenítse meg az SPPS a ke- 
resések eredményeit, és hogyan férhessenek hozzá a fel- 
használók a tartalomhoz az indexelés után. 

3. ,File type" szabályok: Különböző fájltípusok bevétele az 
indexbe, illetve kihagyása onnan (például a .txt és . doc 
típusú dokumentumokat indexelje, de az .exe és .411 
kiterjesztésű fájlokat ne). Csak a munkaállomáson kívüli 
fájlokra érvényes. 


Az alábbi ábra a ShrePoint Portal Server elérési környezetét 
mutatja: 


Internet browser Windows alkalmazás 














Digital web 
Dashboard Folders 
site 
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Tartalomforrások 





I Az SPPS környezete 


Az ábra alsó harmadában a különböző tartalomforrásokat lát- 
hatjuk, amelyeket a SharePoint Portal Server le tud indexelni. 
A szerver szolgáltatásai kétféle módon érhetők el. Egyrészt a di- 
gitális műszerfalon (digital dashboard) keresztül, ami egy we- 
bes felületet biztosít, amelyen keresztül elérhetjük a SPPS mun- 
kaállomásait (egyszerűen csak írjuk be a böngészőbe a megfe- 
lelő címet, fenti példánkban ez 

http: / /mySPPSserver/Agnes). 
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E Az SPPS dashboard site 


A másik elérési mód az, ha az SPPS adattárait webes mappa- 
ként fogjuk fel, és a Windows-alkalmazásokban saját URL-jük- 
kel hivatkozunk rájuk. A továbbiakban ez utóbbi módszerre té- 
rek ki részletesen. 


Az SPPS adatainak elérése programozott módon 


Az SPPS keresőmotorja ADO-n és WebDAV-on keresztül ér- 
hető el. 

Az alábbi ábrán jól látható, hogy a szerverhez mindkét esetben 
XML formátumú kérés jut, és a választ is ebben a formátumban 
kapjuk. ADO esetében az OLEDB Provider feladata a kérés és 
a válasz feldolgozása, így ő játssza a ,közvetítő" szerepét a kli- 
ens és a szerver között. WebDAV esetén közvetlenül az XML 
formátumú kérést adjuk ki, így a hozzáférés sokkal gyorsabb és 
hatékonyabb lehet. 
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1 Az SPPS elérése ADO-val és WebDAV-val 


A módszer megválasztásán túl egyéb megfontolások alapján is 
növelhetjük keresésünk hatékonyságát. Először is a szabad- 
szöveges, illetve a nagy mélységben, vagy távoli kiszolgálón 
történő keresések mind nagyban növelik a végrehajtási időt. 
Szintén lassítja a lefutást a különböző metaadatokra történő 
keresés, hiszen a jellemzők értékét az úgynevezett , property 
store"-ból kell kiolvasni (bár ez cache-elhető a memóriába, 
ami jelentősen gyorsíthatja a futásU. Ha ésszerűen korlátozzuk 
az eredményhalmaz méretét, azaz azt, hogy a keresés maxi- 
mum hány találatot eredményezzen, lényegesen növelhetjük 
a hatékonyságot. A keresőmotor számára azt is megszabhat- 
juk, hogy legfeljebb mennyi ideig próbálkozzon a lekérdezés 
végrehajtásával. A rendezés (ORDER BY) viszont nincs hatás- 
sal a lekérdezés idejére, hiszen vele egy időben kerül végre- 
hajtásra. 

Fontos tényező, hogy keresések esetén a különböző attribútu- 
mokhoz különböző súlyokat rendelhetünk. A nagyobb súllyal 
rendelkező attribútumok számunkra , fontosabb" információt 
jelölnek. 


Például az alábbi kódrészlet azt mutatja, hogy a Subject jel- 
lemző súlya nagyobb (0.8), mint a Title súlya (0.5). 





Az Exchange2000Server WSS-ének elérése az SPPS ke- 
resőmotorjának segítségével 


Ennyi bevezető után lássuk, miként ,házasíthatjuk" össze a 
SharePoint Portal Server keresőmotorját az Exchange2000 Ser- 
ver Web Storage Systemében tárolt adatokkal: (Az SPPS WSS 
hasonlóan érhető el, a különbségekről az [1] címen található 
bővebb információ.) 

A programrészleteket C$-ban adom meg, azt prezentálva, 
hogy .NET alatt hogyan oldható meg a probléma. A kód mag- 
ja, a WebDAV-kérés azonban bármilyen platformról továbbít- 
ható a kiszolgáló felé. 
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Ha az indexelést a fentiek alapján sikeresen elvégez- 
zük, máris megteremtettük az alapfeltételeket, így 
koncentrálhatunk a feladat lényegére. Programunk- 
ban először is adjuk meg az SPPS-munkaállomás és 
az alá indexelt WSS mappa elérési útvonalát: 


77 SPPS TES Rez elérési útvonala: 
string SURL - "http: ./[mysppsserver/Agnes/ "; 
17 Az Exchange2000 Wwss mappájának 

Ül elérés útvonala : - 

string location - 

S "http: : //myExchange2000server/public tree/ 
$ myfolder/"; 





Következő feladatunk a WebDAV-lekérdezés megadása: 


StringBuilder sOuery - new StringBuilder ( ) ; 
sOuery.Append(8"c?xml version-"1.O"?o"); 
sOuery.Append( " cg:searchreguest xmlns:g-"DAV:"!o"); 
s0Ouery.Append( "cg: sal2") ; 

sOuery.Append("SELECT N"DAV:hrefl"] 

4 V"DAV:displaynameN " ") ; 

sOuery. Append ( "FROM. SCOPE(" SHALLOW TRAVERSAL OF 
SZNESA 

sOuery. Append(location) ; 

sOuery.Append ("AV") 9); 
sOuery.Append("c/g:sal:"); 
sOuery.Append("c/g:searchreguesto" ) ; 





A szokásos SELECT lekérdezésről van tehát szó. A SHALLOW 
TRAVERSAL kulcsszóval adjuk meg, hogy csak magában a 
WSS mappában keressen, annak almappáiban ne. Ha ez utób- 
bi funkcióra lenne szükségünk, használjuk a DEEP TRAVERSAL 
kulcsszót. Figyeljük meg, hogy itt még csak az Exchange map- 
pát jelöltük ki, azaz a keresendő információ forrását, hogy ki- 
nek küldjük a lekérdezést, az itt még nem jelenik meg. Így 
ugyanezt a lekérdezést akár magának az Exchange2000 kiszol- 
gálónak is elküldhetnénk. A SharePoint Portal Server ke- 
resőmotorja azonban szélesebb körű szolgáltatásokat nyújt 
számunkra (ilyen például a szabadszöveges keresés az összes 
mappatípusra), ezért esetenként célszerűbb lehet az összetett 
megoldás a WSS-beli adatok elérésére. 

Most következhet a kérés elküldése a megfelelő helyre, ese- 
tünkben az SPPS Agnes nevű munkaállomásának: 


try 

( 

WebReguest reguest - WebReguest.Create(sURL); 
reguest.Method - "SEARCH"; 
reguest.Credentials - new 

4 NetwhorkCredential("user", "password" , 
reguest.ContentType - "text/xml"; 
reguest.Headers[("Depth"] - "1,noroot"; 
reguest.ContentLength - s0Ouery.Length; 


SURL) ; 


StreamWriter writer - new 

b StreamWriter(reguest.GetReguestStream( ) ) ; 
writer.Write(sOuery) ; 

writer.Close(); 


WebResponse response - reguest.GetResponse(); 
Stream stream - response.GetResponseStream( ) ; 
) é 

catch 

( 

hibauzenet - 
hibaUzenet -4- 
hibauzenet -4- 
) 


"Nem sikerult..." ; 
Ági szabadságon van.Mn"; 
sAnyukája e-mailcíme nem publikus."; 


A kiszolgálóhoz történő hozzáférést érdemes egy 
try. .catch blokkban elhelyezni, hiszen itt különösen sok a 
hibalehetőségek száma (pl. a hálózati forgalomnak köszön- 
hetően). 

A WebReguest kérést a következőképpen paraméterezzük: a 
kérést az SURL (azaz a http: //mySPPSserver/Agnes) 
címre küldjük majd, amely esetünkben egy SPPS munkaállo- 
más. A metódus ezúttal keresés (SEARCH), és a user nevű fel- 
használó, password jelszavával kérünk beléptetést. Nagyon 
fontos még a kérés hosszának megadása is (reguest. 
ContentLength), hiszen anélkül (vagy annak rossz beállítá- 
sával) hibaüzenetet kapunk vissza a szervertől. 

Ha mindezzel megvagyunk, egy StreamWriter-t hozunk 
létre, és ennek segítségével küldjük el az sOuery kérést az SPPS 
kiszolgálónak, a fenti beállításoknak megfelelően. 

A választ egy WebResponse típusú változóba kapjuk, amelyet 
a GetResponseStream metódussal egyszerűen streammé 
alakíthatunk, amely a továbbiakban tetszőlegesen feldolgozha- 
tó. (Erre már láthattunk példát korábbi, Exchange2000 Web 
Storage Systemmel foglalkozó cikkemben). 


Összegzésül 

Mindezzel tehát elértük azt, hogy az Exchange2000 Server ke- 
resőmotorját a SharePoint Portal Server keresőmotorjával he- 
lyettesítjük, ezáltal az előbbi funkcionalitását kibővítjük né- 
hány újabb lehetőséggel. Természetesen mint mindennek, en- 
nek is ára van: az SPPS-keresések ugyan különböző módsze- 
rekkel gyorsíthatók, azonban számolnunk kell a két kiszolgáló 
közötti hálózati forgalom sebességcsökkentő hatásával. Helyi 
hálózatok esetében persze ez nem számottevő, azonban nagy 
adatmennyiség vagy távoli kiszolgálók esetében ezt is mérle- 
gelni kell alkalmazásunk infrastruktúrájának tervezésekor. 





Molnár Ágnes 
agnes.molnarOt-systems.com 





(11 http:/msdn.microsoft.com/library/default.asp?url-/library/e 
n-usfwss/wss/sps. store. difís.asp 


Változó dimenziók kezelése Éz 


u] 


weez 


És 


A vállalati adatraktárak időben általában stabilak, azaz többnyire csak új adatok- 
kal bővülnek; a tények elemzésére szolgáló dimenziók azonban idővel megváltoz- 
hatnak. Az eladások adatait elemezhetjük például a , Kereskedők" dimenzió sze- 
rint. A cég kereskedőinek adatai azonban személyes okokból, vagy szervezeti áta- 
lakítás következtében megváltozhatnak. Az ilyen dimenziót szokás , lassan változó 


dimenziónak" nevezni. 


A lassan váltózó dimenziók kezelésének két elterjedt módja 
a felülírás (, restate history") és a változásnaplózás (, track his- 
tory". Ralph Kimball a , The Data Warehouse Toolkit" című 
híres könyvében ezeket a dimenziókat 1-es és 2-es típusúnak 
nevezte. [1] 


Példa lassan változó dimenzióra 


Az előzőekben említett , Kereskedők" dimenzió táblája egy- 
szerűsített formában a következő lehet: 


1 1239 Kelet 1 1999-01-01 
; 
Í 


3 


i 
; 
i 2000-12-01 


4290 ! Nyugat 


Az ,ID" oszlop a kereskedő ,természetes" azonosítója, 
amely állandó a foglalkoztatás ideje alatt, és célszerűen nem 
allokáljuk más alkalmazottnak még akkor sem, ha jelenlegi 
birtokosa már elhagyta a céget. A , Kulcs" oszlop az a mes- 
terséges azonosító, amellyel ez a dimenziótábla a ténytáblá- 
hoz kapcsolódik. 

A valóságban ez a dimenziótábla sok egyéb oszlopot is tar- 
talmaz, például a kereskedő nevét és egyéb személyes ada- 
tait. A személyes adatok változása többnyire 1-es típusú: 
nyugodtan felülírhatjuk a régi értéket az újjal. 

Mi történjen, ha a cégen belüli átszervezés következtében az 
egyik kereskedő területe megváltozik? 

Ha felülírjuk a dimenziótábla adatait és így illesztjük össze a 





ténytáblával, a 8328 azonosítójú kereskedő korábbi eladásai 
is hirtelen egy másik körzetbe kerülnek. 

Ez többnyire helytelen, mert meghamisítja a területi eladások 
adatait. A helyes megoldás a változásnaplózás. 











Lesi) 2 
1 1239 Kelet 1999.01-01 NULL ! Igen 
3 14290 i Nyugat — ; 2000-12-01 Í NULL / Igen 


i 


A dimenziótáblát egy új sorral bővítettük, amely az új hely- 
zetet mutatja. A ténytáblában a kereskedő korábbi eladásai a 
2-es kulccsal szerepelnek, az új eladások a 4-es kulcshoz 
fognak tartozni. 


Felülírás és változásnaplózás egyszerre 


Olykor felmerül az igény, hogy egy dimenzió esetén mindkét 
változáskövetési módszert megvalósítsuk. 

A példában változásnaplózás megfelelő a területre történő 
felösszegzés szempontjából, de nem jó a kereskedőnek, aki- 
nek a prémiuma az eladásoktól függ. Ha gyorsan szeretnénk 


te S WET E. wv i 


megtalálni, hogy a különböző kulcsok közül melyek azono- 
sítják ugyanazt a személyt, célszerű felvenni még egy oszlo- 
pot, amely az adott ID-hez tartozó első kulcsot tartalmazza. 
Redundáns táblát kapunk, hiszen az [ID] és a IKezdés] osz- 
lopok alapján az (Első Kulcsl előállítható, de ezt a redundan- 
ciát a későbbi feldolgozási sebesség érdekében vállaljuk. 





Kulcs ID Terület Kezd Befejez Aktuális? Első Kulcs 
1 — 71239 (Kelet 1999-01-O1 " NULL igen 1 
2 — 8328 ; Kelet 2000-07-O1 ) 2002-11-24 ! nem 2 
3 4290 ÍNyugat /2000-12-01 ! NULL "igen 3 
4 — 18328 ÍNyugat 12002-11-25 Í NULL igen 7 


A tábla változatlanul a historikus megközelítést mutatja, de 
könnyen építhetünk rá egy aktuális nézetet. 


CREATE VIEW [KereskedőkAktuális] AS 
SELECT lElső kulcs], [ID], [Terület], stb. 
FROM [Kereskedők] e Ez 

WHERE [Aktuális?] - "igen" 


Ha a ténytáblát hozzá tudjuk kapcsolni a IKereskedőkAktuá- 
lis] viewhoz, készen is vagyunk. Kisebb méretű ténytábla 
esetén egyszerűen felvehetünk egy új idegen kulcsot tartal- 
mazó oszlopot. Nagy, sok milliárd soros ténytábla esetén 
azonban célszerű takarékoskodni a hellyel. Minden bájt, ami 
hozzáadódik a ténytábla szélességéhez, megszorzódik a so- 
rok számával. A megoldás ismét egy view lehet: 


CREATE VIEW [TényKétNézetben] AS 

SELECT [(Tény].t, [Kereskedők] . (Első Kulcs] 

FROM [Tény] at 

INNER JOIN [Keresked k] 

ON [Tény)].([Kulcs] - [Kereskedők] . [Kulcs] 

Az Analysis Servicesben ezután két dimenziót készíthetünk. 
A IKereskedőkl] tábla alapján készített dimenzió a változás- 
naplózást mutatja. A IKereskedőkAktuális] view alapján ké- 
szített dimenzió pedig a felülírással aktualizált állapotnak fe- 
lel meg. (Ez utóbbi dimenziót célszerű ,Changing Dimensi- 
on"-nek deklarálni.) Az OLAP-kockánk ténytáblája a (Tény- 
KétNézetben] view lesz. A viewban szereplő join egy kicsit 
lassíthatja a feldolgozást, de nem jelentősen. Ha a többi di- 
menzió miatti joinokat ,kioptimalizáljuk" , a kocka feldolgo- 
zása még így is nagyon gyors lesz. 

Joy Mundy (Microsoft) írása alapján 


Kószó Károly 
karolykemicrosoft.com 
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Feltörhetetlen bejelentkezés" 


Challenge/Response, Kerberos 


és Smart Card logon 


A szoftveripar nagyjai már sokszor megígérték nekünk, hogy egyszer s mindenkorra véget vetnek a be- 
jelentkezési (autentikációs) adatok lopkodásának. Ismerjük a LanMan/NTLM páros szomorú sorsát 
(LOPHTCrack), s most már az utóbbi években folyamatosan magasztalt Kerberost is utolérte a sorsa 
(Kerbcrack)! Egyetlen megoldási lehetőségnek a jelszavas bejelentkezés kiiktatása, elfelejtése látszik. 
Az intelligens kártyás bejelentkezés az új ígéret. Ez azonban -— elődjeitől eltérően — be fogja váltani a 


hozzáfűzött reményeket, mert... 


Mielőtt belemerülnénk a kártya dugdosásába, röviden tekint- 
sük át mind az NTLM Challenge/Response, mind a Kerberos- 
protokollt. Előbbit azért, hogy lássuk, miért volt nála százszor 
jobb a Kerberos V5. Utóbbi azért, mert a kártyás bejelentkezés 
nem helyettesíti, hanem átalakítja a Kerberost. A hitelesítés fo- 
lyamata 9599-ban megegyezik a jelszavas és a kártyás Kerbe- 
rosnál is. 


Jelszótárolás 


A hitelesítési mizéria megértéséhez külön kell választanunk a 
hálózati bejelentkezési protokollok működését a jelszavak táro- 
lásának módszereitől. Először foglalkozzunk a jelszótárolással. 
Az általános hiedelemmel ellentétben a Windows nem tárolja 
a felhasználók jelszavait, csak az abból készített hash-eket. Ezt 
azonban mindjárt két változatban: egy gyenge (LanMan) és egy 
erős (NTLM) formátumban. 

Mivel a jelszavak nem tárolódnak, felmerül a kérdés, hogy a 
csudába lehet azokat visszafejteni. A hash-algoritmus olyan, 
mint egy húsdaráló: felül bemegy a nyuszi, alul kijön egy rá 
jellemző fasírt, de a folyamat fordítva NEM végezhető el! Fa- 
sírtból nem lehet nyulat csinálni. 

A kérdés általánosítható: mit jelent egy hash-algoritmus feltöré- 
se? Addig feszegetem a húsdarálót, amíg el nem kezd visszafe- 
lé működni? Nem! A cél olyan kiinduló adat (nyuszi) találása, 
amit ha ledarálunk, ugyanahhoz a fasírthoz jutunk. Ezresével 
daráljuk a nyuszikat, hátha az egyik ,jó" fasírtot ad. 

Mivel a mai napig senki sem bizonyította be a hash-algoritmu- 
sok (MD5) működőképességét (csak használjuk, és bízunk 
benne, hogy különböző adatokra különböző kimenetet ad), 
a nyers erővel (brute force) végzett tömeges nyúldarálás vé- 
gén lehet, hogy nem az eredeti jelszóhoz jutunk, hanem egy 
olyan karaktersorozathoz, mely - véletlenül — pontosan 
ugyanazt a hasht adja, mint a keresett jelszó. Az esetek 
99 ,99999999999999-ában egyébként a valódi jelszó ad jó 
megoldást, tehát a hashalgoritmusok (többsége) jó munkát 
végez. 

Lehetőség van a jelszavak eredeti, olvasható alakjának 
megőrzésére is, ez külön erőfeszítést igényel a rendszergazda 
részéről: minden egyes felhasználón be kell pipálni, hogy az il- 
lető jelszavát őrizze meg a Windows. Erre akkor lehet szükség, 
ha a DC-nek olyan harmadik kiszolgáló felé kell azonosítania 
minket, akivel a Basic (clear text) azonosítás a közös nevező. 
Az alábbi ábrán láthatjuk, hol lehet ezt kérni az Active Direc- 
torytól: 
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Environment ] Sessions l Remote control 
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B Az Active Directory lehetővé teszi a felhasználói jel- 
szavak megőrzését, de ezt külön kérnünk kell 


LanMan és NTLM 


Az NTLM-hash nem más, mint MD4, szerencsére éppen ezt 
használja a Kerberos protokoll is, így harmadik jelszótárolási 
formátumra már nincs szükség. 

Érdekesebb jószág a LanMan-hash. Az itt alkalmazott , varázs- 
kódolásnak" köszönhető, hogy az NT4 biztonsága oly sok kí- 
vánnivalót hagy maga után: a ,varázskódolás" (security by 
obscurity) sohasem hozza meg a kívánt eredményt. Egy jó de- 
bugger és megfelelő mennyiségű idő birtokában akármelyik 
egyetemista tetszőleges, ismeretlen DLL-ről felkommentezett 
forráskódot ad. Nem meglepő, hogy a LanMan-eljárás is pórul 
járt. Íme a LanMan lépései a jelszóalapú bejelentkezés során: 


1. A jelszó nagybetűsítése (UPPERCASE) 

2. A jelszó kiegészítése szóközökkel, 14 bájt 
hosszúságra 

"3. A 14 bájtos jelszóból (14 " 8 - 
bit) 2 db DES kulcs készül 

4. A két 56 bites DES kulccsal titkosítjuk a 
0x4B47532140232425 "mágikus" számot 

5. Az eredmény 28 bájt, összesen 16 bájtos "HASH" 


EL EZ e ezte 5 6 


A fenti lépéssorból kiolvasható, hogy ha a jelszó rövi- 
debb, mint 8 karakter, a ,hash" második fele mindig 
0xAAD3B435B51404EE, hisz konstanssal (csupa szóközzel) 
titkosítjuk a szintén mindig állandó , mágikus" számot. Ennek 
köszönhető, hogy a LOPHTCrack (és társai) hamarabb megfej- 
tik a nyolcadik karakter utáni jelszórészt, mint az elejét, hisz 
egy már meglehetősen bonyolultnak számító 9 karakteres jel- 
szó erőssége megegyezik egy 7--2 karakteresével. A kétkarak- 
teres hátsó fél feltöréséhez másodpercek (sem) kellenek. 

De figyelemre méltó az UPPERCASE is, mert emiatt felesleges 
a jelszót kis- és nagybetűkkel tarkítani — úgyis elvész ez az in- 
formáció. 

Ha a LanMan-jelszótárolás engedélyezve van, akár ne is 
erőltessük a 7 karakternél hosszabb és bonyolult jelszavakat. 
Erre a két jelszótárolásra, mint ,biztos" alapra épülnek a háló- 
zaton keresztüli felhasználóazonosítás protokolljai, a Challen- 
ge/Response és a Kerberos. Ez utóbbinál csak az NTLM-hash 
dolgozik (MD4), emiatt ez a hitelesítés egy jó nagyságrenddel 
biztonságosabb, mint a Challenge/Response — de ez is rogya- 
dozik már. 


Challenge/Response 


Az NTLM-alapú Challenge/Response-protokoll volt a Win- 
dows-világban az első hitelesítési eljárás, melyet — legalábbis 
egy darabig — biztonságosnak lehetett tekinteni. Maga a Micro- 
soft is tett olyan kijelentéseket, hogy ennek feltörése puszta áb- 
ránd, fikció, hisz a jelszavak kódolására használt MD4 hashal- 
goritmus állja a hackerek rohamát (ez ma már nem igaz). A be- 
jelentkezési adatok titkosításához használt, állandóan változó 
Challenge pedig eléggé összekuszálta a szálakat ahhoz, hogy 
emberi elme ne tudja kibogozni. Hogyan is működik? 

A Challenge/Response erejét az adja, hogy minden egyes beje- 
lentkezés előtt a hitelesítést végző számítógép átküld a kérel- 
mezőnek egy nyolcbájtos , kihívást", amit annak megfelelően 
titkosítania kell. Tehát nem a jelszóT, hanem a jelszóvAL titko- 
sítunk egy véletlenszerű adatot. Az alábbi ábra ezt a folyama- 
tot mutatja: 


3.4 Hasht 


s: Hash! 
A 


1. Be szeretnék jelentkezni 
2. Ezt használd titkosításkor! (KIHÍVÁS) 


4. Név, VÁLASZ (a jelszó helyett) 


6. Rendben/Elutasítva 


E A Challenge/Response folyamata 


Hogyan zajlik a kihívás titkosítása? A felhasználó által begépelt 
jelszó alapján a munkaállomás előállítja a LanMan és NTLM- 
hasheket. Mint azt fentebb láttuk, ezek mindegyike 16 bájtos. 
Ha hozzácsapunk még 5 bájtot (csupa nullát), 21 bájthoz ju- 
tunk, ami testvérek között is három darab DES-kulcs. Nos, 
mindhárommal (mindhattal, hisz két jelszóváltozatunk is van) 





titkosítjuk a kihívást, így összesen 8--8--8--8--8--8 
bájtnyi válaszhoz jutunk. Ezt küldjük vissza a DC- 
nek, aki saját oldalán kiássa a címtárból mind a Lan- 
Man, mind az NTLM-hasht, szintén elvégzi a titkosí- 
tást, és ha azonos eredményre jut, mint a kérelmező, 
megadja az engedélyt. 

A Challenge/Response ellen remekül használható az úgyneve- 
zett known-plaintext kriptoanalízis, hisz a kihívás (az eredeti 
adat!) birtokában kell megtalálnunk azokat a DES-kulcsokat, 
amivel betitkosították. (Tehát nem az adatot, hanem a kulcso- 
kat keressük.) A kulcsok összessége nem más mint az NTLM és 
a LanMan-hash. És itt a vége. 

A Challenge/Response halálát a LanMan ,titkosítás" okozza, 
mivel a két jelszóhash kölcsönösen gyengíti egymást. A Lan- 
Man-hash alapján könnyűszerrel visszafejthető a jelszavak 
nagybetűs változata. Az MD4-hasht már csak ennek külön- 
böző kis- és nagybetűs kombinációival kell , megetetni", és 
máris miénk az eredeti jelszó. 

Ezt a gyengeséget azzal tetézi a Challenge/Response, hogy 
minden egyes új hálózati kapcsolatnál újra és újra lefut, tehát 
egy adott felhasználó jelszavai(ból képzett adatok) naponta 
kismilliószor jelennek meg a hálózaton, ráadásul itt nem rész- 
letezett okokból kifolyólag (Pass Thru) gyakorlatilag a hálózat 
minden zugában felbukkanhatnak. Ha öt percig futtatunk egy 
sniffert, valószínűleg a dolgozók felének jelszavához hozzáju- 
tunk. Ezzel szemben a Kerberos... 


- 


Kerberos 


A Kerberos úgynevezett jegyalapú hitelesítést használ, amely- 
nek az a lényege, hogy egy kezdeti (reggel 8) azonosítás után 
a hálózati erőforrások eléréséhez már nem jelszóhasht, hanem 
jegyeket használ. Ebben a cikkben nem térek ki részleteiben a 
Kerberosra, hisz ezt korábban (2 éve) már megtettük, s a cikk 
kikerült a Netacademia tudásbázis webre is [1]. 

Ami azonban fontos, az a kezdeti azonosítás. Ehhez bizony to- 
vábbra is jelszóalapú adatra van szükség, hacsak ki nem vált- 
juk ezt Smart Carddal. De egyelőre ne váltsuk ki! 
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a A Kerberos-azonosítás első lépése az Authenticator 
(hitelesítő) adatokkal 


A kezdeti azonosítást az Authentication Service végzi. Az eljá- 
rás hasonlatos a Challenge/Response szisztémához, tehát nem 
a jelszóT, hanem a jelszóvAL titkosítunk valamit, nevezetesen 
a munkaállomás rendszerórájának állását. Ezt a tartományve- 
zérlő megpróbálja kibontani a nála tárolt jelszóhash segítségé- 
vel. Sikeresség esetén még egy ellenőrzés történik, nevezetesen 
a kibontott csomagban található óraállást a tartományvezérlő 
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EJg összeveti a saját óraállásával. Ha az eltérés nagyobb 


öt percnél, ijedten eldobja a csomagot és rendőrért 
7 kiált. Ez logikus védekezés az úgynevezett visszaját- 
szási (replay) támadás ellen, amikor egy gonosztevő, 
aki nem tudja a Vezérigazgató jelszavát, beküldi az 
Authentication Service-nek a Vezér által korábban küldött be- 
jelentkezési adatokat. 
Ilyen huncutságra tehát összesen öt percünk van. Félek, hogy 
előbb-utóbb lesz megfelelő eszköz, amivel abszolválható e 
tempó, s ez ráadásul a Smart Card-bejelentkezésre is vesz- 
élyessé válhat. Ebből a szempontból a Challenge/Response 
erősebb, mert egy adott kihívásra (emlékezzünk: 8 bájtos adat) 
csak egyetlenegy (helyes) választ fogad el, így a visszajátszás 
tökéletesen értelmetlen; az a vonat elment. 


KerbCrack 


Igaz ugyan, hogy a Kerberos naponta csak egyszer fed fel bár- 
milyen adatot a felhasználó jelszaváról, de akkor megteszi. 
Van már ügyes eszköz a Kerberos AS-forgalom figyelésére és 
elkapására, ez a KerbCrack néven futó (letölthető) tünetegyüt- 
tes. Nincs mit tenni, be kell vallani, hogy az MD4-hash ma 
már, a 2 GHz-es személyi számítógépek korában halottnak te- 
kinthető. 
Egy korábbi cikkemben említettem a jelszóparadoxont. Egy jel- 
szó legyen: 

A Bonyolult 

HA Hosszú 

A Megjegyezhető 


Sajnos a valóságban ebből a három feltételből rendszerint ma- 
ximum kettő teljesül. Több kiút is lehetséges, ezek közül nap- 
jainkban a Smart Card-alapú bejelentkezés került elérhető kö- 
zelségbe. A kártyák és olvasók ára zuhanórepülésbe kezdett, a 
többi infrastrukturális elem (Certificate Server stb.) pedig ,in- 
gyen" van annak, aki megvásárolta a Windows 2000 Servert. 


Smart Card logon 


És most térjünk rá a Smart Card logonra, az intelligens kártyá- 
val végzett bejelentkezésre. A felhasználó szemszögéből a vál- 
tozás annyi, hogy már nemcsak egy jelszójellegű izét kell tud- 
nia (PIN-kód), hanem valamivel rendelkeznie is kell — a kártyá- 
val (vagy USB-tokennel). A PIN-kód nem megy át a hálózaton, 
hanem a Crypto API-n egyenesen áthaladva a kártyához tarto- 
zó Crypto Service Provider segítségével lejut az eszközbe. Ez 
az útvonal gyakorlatilag lehallgathatatlannak tekinthető, így a 
PIN-kódnak korántsem kell olyan hosszúnak és bonyolultnak 
lennie, mint egy hagyományos jelszónak. 

Ráadásul több kártya is rendelkezik önmegsemmisítő szolgál- 
tatással, vagyis x darab hibás bejelentkezés után használhatat- 
lanná válik. 

Mit tudnak az intelligens kártyák? Mindenféle titkosítási algo- 
ritmusokat futtatni. A hash-algoritmusok közül általában tudják 
az MD4, MDS5, SHA változatokat, a szimmetrikus titkosítóalgo- 
ritmusok közül a DES, DESX, 3DES, RC4, RC5 típust, a nyílt 
kulcsúak közül pedig az RSA-t és a DSA-t. 

Erre a bázisra alapozva lehetővé válik a Kerberos kezdeti hi- 
telesítési lépésének átterelése a kártyára, mégpedig a követ- 
kező módon: az azonosítás során az Authenticator mezőt nem 
a jelszóból képzett adattal, hanem a kártyán lévő — és azt so- 
ha el nem hagyó - privát kulccsal titkosítjuk. Ezt küldi el a 
munkaállomás a tartományvezérlőnek. A DC a beérkezett 
csomagból kiolvassa a felhasználó nevét és előkeresi a címtár- 
ban publikált tanúsítványok közül azt, amelyikben a megfe- 


lelő publikus kulcs rejtőzik. Ezzel kinyitja az Auth. mezőt, és 
innentől minden ugyanúgy zajlik, mint a korábbi, jelszavas 
bejelentkezéskor. 


Feltörhető? 


A security levelezési listán kérdezte valaki, hogy a Smart Card 
bejelentkezés is csak időleges megoldás-e, magyarán: feltör- 
hető lesz-e valaha? 

Erre egyértelmű választ adhatok. A Kerberos Auth. csomag 
éppúgy hajlik a ,known plaintext" visszafejtés előtt, mint a 
Challenge/Response. De ne feledjük, mi a jutalma annak, aki 
végigpróbálgatja a feltöréshez szükséges hatalmas kulcsmezőt: 
szert tesz arra a kulcsra, amellyel a csomag bontható. 
Szimmetrikus titkosítás esetén, amikor a titkosító kulcs meg- 
egyezik a kibontókulccsal a megfejtő jutalma egy jelszó. 

Nyílt kulcsú titkosítás bevetésével a helyzet gyökeresen meg- 
változik. A véres verítékkel, próbálgatásos módszerrel megfej- 
tett kibontókulcs nem más, mint az RSA-kulcspár publikus tag- 
ja, amihez minden erőfeszítés nélkül is hozzájuthatott volna a 
nyomorult hacker — hisz azért publikus! 

Ami veszélyesnek tűnik az a visszajátszásos támadás (replay 
attack). Emlékezzünk vissza: öt percünk van arra, hogy beküld- 
jünk egy helyes Auth. csomagot! 


Biometrikus megoldások 


Végül ejtsünk néhány szót a biometrikus azonosítási módsze- 
rekről is. Akármelyikkel találkoztam (pl. ujjlenyomatolvasó), 
azt tapasztaltam, hogy ezek csak jelszópótlóként használha- 
tók. Az ujjlenyomatolvasó azonosítja becses személyemet, ez 
alapján kikeresi a saját dugi raktárából a jelszavamat, és elkül- 
di a tartományvezérlőnek. Hangsúlyozom: elküldi! A jelsza- 
vam! A hálózaton át! 

Ezek tehát csak akkor érnek valamit, ha megszigorítjuk a jel- 
szavas bejelentkezést: letiltjuk a LanMan-jelszótárolást stb. 
Amíg a biometrikus eljárások támogatása be nem épül a tarto- 
mányvezérlőkbe, addig ez a módszer játék marad. 

(Az IDENTIX cég rendelkezik kiszolgálóoldali ujjlenyomattelis- 
merővel, de annak ellenére nem adta ki tesztelésre, hogy re- 
gisztrált ujjlenyomat-olvasó felhasználó vagyok.) 


Fóti Marcell 

marcellfonetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


A cikkben szereplő URL-ek: 
11] NetAcademia tudásbázis, a Kerberos-protokoll 
http://www.netacademia.:net/secu/kerberos 


Meeke 
SECU — Hálózatbiztonság (12 óra) 

PKI Workshop (2 nap) 

2150 - Windowsos hálózatok biztonsága (40 óra) 


oarttart Lard logon 


Lépésről lépésre 
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Najaink legmegbízhatóbb felhasználóazonosítási módszere az intelligens kártyás bejelentkezés. Ha a 
megfelelő hardvereszközök rendelkezésre állnak, neki is láthatunk a rendszer bevezetésének. Szüksé- 
günk lesz Certificate Serverre, egy Smard Card-író ,műhelyre", csoportos házirendek állítgatására és 
még sok minden másra. Ha bármelyik lépést kihagyjuk, egzotikus hibaüzenetekben gyönyörködhe- 
tünk. Ez a cikk a Smart Card logon elkészítésének ,szakácskönyve"! 


Egy jó szakácskönyv a hozzávalók felsorolásával kezdődik, 
hogy a háziasszony mindent a keze ügyébe készíthessen. Én is 
követem ezt a szerkesztési módszert. 


A Smart Card logon feltételei 


1. Olyan operációs rendszerek kellenek mind ügyfél-, mind 
pedig kiszolgálóoldalon, amelyek támogatják ezt a beje- 
lentkezési formát. Javaslom az NTA, mint őskövület elfelej- 
tését, bár hallomásból tudom, hogy több kártyagyártó ren- 
delkezik NT4-en is működő megoldással. Ebben a szakács- 
könyvben csak a Windows 2000 (és utódai) által gyárilag 
támogatott, Kerberos-alapú kártyás bejelentkezéssel foglal- 
kozom. 

2. Ha már ragaszkodom a Kerberos-alapú megoldáshoz, ez- 
zel azt is meghatároztuk, hogy Active Directoryt kell hasz- 
nálnunk. Ez a címtár — sok egyéb adat mellett — a felhasz- 
nálók tanúsítványainak tárolására is fel van készítve. 

3. Szükségünk lesz a Windowshoz tartozó Enterprise Certifi- 
cate Authorityra is, amelyik két fontos dologra képes. Egy- 
felől csak az Enterprise-változat képes és a megfelelő tanú- 
sítványsablonok (template) kiállítására, másfelől a kész ta- 
núsítványokat (benne ugyebár a publikus kulccsal) auto- 
matikusan elhelyezi a címtár megfelelő rekeszében (a 
megfelelő felhasználónál)). 

4. A kártyák készítését nem a végfelhasználó, hanem egy 
úgynevezett Smart Card kiállító személy végzi. Ennek az 
első pillantásra szokatlan, kényelmetlen megoldásnak biz- 
tonsági okai vannak: ezzel elkerülhető, hogy boldog-bol- 
dogtalan kártyakiállítói jogosultsággal rendelkezzen. A Jo- 
gosult Személy a Kártyakiállító Központban végzi felada- 
tát, vagyis egy erre a feladatra elkülönített PC előtt ül. A 
PC-re természetesen tegyük fel a kártya kezeléséhez szük- 
séges eszközöket, programokat, eszközmeghajtókat. A 
kártyagyártó személy tetszőleges felhasználó nevében ké- 
szíthet új kártyát. Ha ezzel a lehetőséggel visszaél, az 
egész rendszer nem ér semmit. 

5. Előkészített kártyák, tokenek. A kártyák formázását, a PIN- 
és PUK-kódok beállítását jobb előre elvégezni, így gördü- 
lékenyebb a kártyagyártás. Sok kártyánál (és a PKI Work- 
shopon használt USB-tokennél is) alapértelmezett kulcs- 
tárrá kell tenni azt a rekeszt, amelyikben a logon-kulcspár 
csücsül. 


Ha ez mind megvan, sorozatban lehet generálni a kártyákat. 
Most lássuk részletesebben a harmadik pontot! 


Certificate Server telepítése 


A Windows 2000 telepítőlemeze tartalmazza a Tanúsítványki- 
állító Központot, a Certificate Authority szolgáltatást. VVin- 
dows-komponensről lévén szó, telepítése megegyezik — mond- 
juk — a DHCP Server telepítésével, azaz Control Panel Add/Re- 
move Programs Windows Components. Amire vigyázni kell: a 
Certificate Server bebetonozza a kiszolgáló aktuális állapotát. 
Ha feltettük, többé nem változtatható sem a gép neve, sem tar- 
tományi tagsága! 

Mivel Enterprise CA-t szeretnénk telepíteni (és ez Active Direc- 
toryt igényel), a kiszemelt CA-kiszolgálónak a telepítés pillana- 
tában vagy tartományi tagnak, vagy egyenesen DC-nek kell 
lennie. Ha ez nem teljesül, sajnos csak önálló (Standalone) CA- 
t tudunk telepíteni — az Enterprise... gombok szürkék lesznek. 
Jelen leírásban egyszerűségre törekszem, így minden további 
hókuszpókusz nélkül válasszuk az Enterprise Root CA telepíté- 
si változatot. 


EIMTETEETETET ETET ax 


Centification Authority Type 
There are four types of certification authorities. 











Certification Authority types: 
6 Emerpáse root CA 

C Enterprise subordinate CA 
€ Stand-alone root CA 

€C Stand-alone subordínate CA 








E Enterprise Root CA telepítése 


Tanúsítványsablonok (certificate template) 


Miért is ragaszkodunk az Enterprise opcióhoz? Mert csak ez a 

változat képes a kártyás bejelentkezéshez szükséges tanúsít- 

ványtípusok előállítására. A sablon meghatározza a kulcsok 

felhasználási területeit. Három különleges tanúsítványsablonra 

lesz szükségünk: k 

1. A kártyák készítését egy úgynevezett Enrollment Agent vég- 
zi (hús-vér ember). Említettem, hogy ezt a feladatot csak a 
megfelelő jogosultság birtokában lehet elvégezni. Nos, a 
jogosultságot stílszerűen egy megfelelő tanúsítvány birtok- 
lásával bizonyítja az ügynök. Smart Card íráshoz tehát a 
következő tanúsítvánnyal kell rendelkezni: Enrollment 
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Agent (EA). Ehhez a tanúsítványhoz nyilván tartozik 
! egy kulcspár is, amelyet akár Smart Cardon is tárol- 
] hatunk, de ez nem kötelező. Alapértelmezésben ki- 

zárólag a Domain Admins csoport tagjai kérhetnek 

EA-tanúsítványt, de ez megváltoztatható az Active 
Directory Sites and Services eszközzel (ennek bemutatása 
túlmutat a cikk keretein). 
2. A kártyák felhasználói pedig olyan tanúsítványokat kapnak, 
amelyek a bejelentkezéshez szükségesek. Vagy Smart Card 
Logon (csak bejelentkezésre) vagy Smart Card User (beje- 
lentkezés--email) típusú tanúsítvánnyal kell rendelkezniük. 


E három tanúsítványtípus sajnos nem kerül be gyárilag a Certi- 
ficate Server által kiosztott sablonok közé, külön engedélyez- 
nünk kell ezek használatát a Certificate Authority MMC-konzol 
segítségével. Az alábbi ábrán jól látható, hogy a Policy Settings 

















gs ágon kell jólirányzott klikkeléseket elhelyezni: 

a. 
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A megjelenő ablakban egyszerre akár mindhárom tanúsítvány- 
típust is kijelölhetjük, csak tartsuk szorosan fogva a CTRL bil- 
lentyűt! 













MESS ásza 


Select a certificate template to issue certificates 





Secure Email, Ci 


her 
Client Authenticatic 
Client Authenticati. 





Code Signing 
Trust List Signing Microsoft Trust List 
Enrollment Agent Certificate Reguest 
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E Az Enrollment Agent és a két Smart Card-sablon egy- 
idejű engedélyezése 


Kártyakiállító központ 

A megfelelő sablonok engedélyezése után hamarosan indulhat 
a munka, előtte azonban a kártyákat kiállító személynek szert 
kell tennie egy Enrollment Agent tanúsítványra, mert ezzel fog- 
ja bizonyítani, hogy jogosult más nevében kártyákat kiállítani. 
Ehhez elindít egy böngészőt, és megnyitja a Certificate Servert 
futtató gépen a http://gepneve/CeriSrv lapot. Jól jegyezzük meg 
ezt az útvonalat, ez a tanúsítványkérési webhely címe, mindig 
ide kell visszatérnünk, ha a kiszolgálótól tanúsítványt kérünk. 
Az alábbi ábrán összesűrítettem az Enrollment Agent tanúsít- 
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vány kérésének lépéseit (egyébként Advanced Reguest, Using 


a Form...) 
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TSTIMTat VOTTSJ UBS 


Select a task: 
Retrieve the CA certificate or 
certificate revocation üst 
OReguest a certificate 
Check on a pending 
— certificate 


0 Trusted stes 


A Microsoft Certificate Servic... ( (5650 
Elie Edt Vew Favortes Ioos 1? 4 
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0 Submit a certificate reguest tö 
this CA using a form. 


0 Subrmit a certificate reguest 
using a base64 encoded 
PKCS $10 file or a renewal 
reguest using a base64 


O User certificate reguest 
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0 Advanced reguest 
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EFS Recovery Agent 
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encoded PKCS $7 file. 


. O Reguest a certificate for a 


€) Done O Irusted stes 


E Enrollment Agent tanúsítványkérés (Az utolsó ábrán 
rossz helyen áll a kurzor. Fáradt voltam...) 


Kártyák készítése 

A kártyák készítése kísértetiesen hasonló módon történik, csak 
a web egy másik ágán (Advanced Reguest, For Smart Card on 
behalf of another user... .), azzal a nem elhanyagolható különb- 
séggel, hogy most a tanúsítvány típusa Smart Card ", a kulcs- 
pár helye nyilván a kártya, a célszemély pedig egy hagyomá- 
nyos felhasználó (Kőműves Kelemen). Az utolsó lépés képer- 
nyőjét mutatom, mert szépen összefoglalja mindazt, amit eb- 
ben a bekezdésben írtam: 








Smart Card Enrollment Station 





fnrollment Options: 
Cenécate Tomgiate [Smancsraüser 3] 
Cenfkeation Authorgy [Főisra7 Ez] 


Cryntograptve 
Seruce Pronder 


Rdmánáztrator 
Signng Cetácate E Sákoatosttésttl 


ser To Enrolt: 
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2 Smartcard User tanúsítvány kérése Kőműves Kelemen 
részére, ActivCard Gold kártyára 


Az Enroll gomb megnyomása után a kiválaszott Crypto Servi- 
ce Provider (esetünkben ActivCard Gold) érzékeli a kulcsgene- 
rálási kérést, és feldob egy PIN-kód ablakot. Ha sikeresen elta- 
láljuk a PIN-kódot, a kulcsgenerálás megtörténik lent az esz- 
közben, majd a publikus kulcs elvándorol a Certificate Server- 
be, ahol rákerül egy digitális aláírás a CA privát kulcsával, 
vagyis előáll egy tanúsítvány. Ezt azután a CA automatikusan 





beledobja az Active Directoryba is — nomeg vissza is küld egy 
példányt nekünk. Ezt az oprendszer letölti a kártyára, így azon 
a műveletsor végére három objektum található: 

TA egy privát kulcs 

A egy hozzá tartozó publikus kulcs 

TA egy a publikus kulcs hitelességét igazoló X.509 tanúsít- 

vány. 

Mindez meg is tekinthető a kártyához adott kezelőszoítver se- 
gítségével: 


ActivCard Gold Utilities 


Ép Adrministrators smart card 
6 PIN 
(CI Auiek Fill 
CI Network Login 


ja CI Digital Certificates 





Kőműves Kelemen bejelentkezési tanúsítványa Actív- 
Card Gold kártyán 


Itt jegyzem meg, hogy -— jól láthatóan — a tanúsítvány NEM a 
Network Login" bugyorba került — mert nem az ActivCard sa- 
ját rendszerét használjuk, hanem a Windows 2000-ét. Ebből 
különböző galibák szoktak származni abban az esetben, ha 
több tanúsítvány is van a kártyán. Aki játszott S/MIME-mal 
vagy SSL-lel, tudja jól, hogy mindig pontosan be kell állítani, 
melyik tanúsítványt használja a rendszer. A Smart Card logon- 
nál nincs ilyen beállítási lehetőség. Ez mindig az alapértelme- 
zett tanúsítvánnyal és kulcspárral próbálkozik — még ha az 
nem is megfelelő típusú! Tegyük alapértelmezetté a logon-ta- 
núsítványt! 


A kártya használata 


Talán feltűnt, hogy ezidáig csak a Certificate Serverrel játsza- 
doztunk, a tartományvezérlőnek nem kellett elmagyaráznunk 
a Smart Card logon mibenlétét. Ez azért van így, mert ez a faj- 
ta bejelentkezési mód az Active Directory alapértelmezett hi- 
telesítési eljárásai közé tartozik! Immár három éve! 

De lássuk tovább a folyamatot: a felhasználó kézhez kapja a 
kész kártyát, elballag vele a saját gépéhez, ám a bejelentkező- 
képernyőnél nem CTRL--ALT--DEL akkordot nyom, hanem be- 
illeszti a kártyát az olvasóba (vagy bedugja a tokent az USB- 
hubba), majd a megjelenő ablakba begépeli a kártyához tarto- 
zó PIN-kódot. 


HA a PIN-kód nyitja a kártyát 

TA a kártya titkosítja a Kerberos Auth. mezőt 

TA a gép elküldi a tartományvezérlőnek a KRB AS REO 
csomagot 

HA a DC kiolvassa a felhasználó nevét a csomagból, és 
megkeresi a számára publikált Smart Card " tanúsítvá- 


nyokat 
TA a megfelelő tanúsítványból kiolvassa a megfelelő pub- 
likus kulcsot 
TA kinyitja vele az Auth. mezőt 
H a csomag küldője tehát rendelkezik a privát kulccsal. 
Login. 
tech. wwzrádig vi 





További beállítási lehetőségek £] 
Az egyik legfontosabb beállítási lehetőség a hagyo- ha) 


mányos (jelszavas) bejelentkezés tiltása. Mivel ennek ! 
csak azoknál a felhasználóknál van értelme, akik már 
rendelkeznek megfelelő kártyával, ez a beállítás fel- 
használói fiókonként egyedi. Keressük meg a célszemélyt az 
Active Directoryban, és a tulajdonságlapján pipáljuk be a 
Smart Card is reguired..." pipát: 





2 A rKkártyahasználat kötelezővé tehető! 


Egy másik fontos beállítási lehetőség a kártya eltávolítására 
adott válaszlépés. Alapértelmezésben a válasz: hallgatás. Ha 
kihúzzuk a kártyát, nem történik semmi. De lehetőség van ar- 
ra, hogy a kártya kihúzásakor 

A zárolódjon a munkaállomás (Lock Workstation) vagy 

A a felhasználót a rendszer jelentkeztesse ki (Force Logoff?. 
Ez a két lehetőség különösen ajtónyitóval integrált kártyák ese- 
tén váltja be a hozzá fűzött reményeket, mert a felhasználó 
kénytelen magával vinni a kártyáját, ha elhagyja a szobáját. Ez 
a beállítás csoportos házirenddel (Group Policy) módosítható: 


Pubi Key Polcie 


j rsaxevratojül jötrengthen defaut permissions of giobal syst... Not defined 


E Mi történjen a kártya kihúzásának hatására? 


Érdekes, hogy ez a beállítás gépszintű (lásd az ábrán), azaz egy 

adott PC-re, és nem egy adott személyre vonatkozik. Olyannyi- 

ra nem, hogy ha nem is kártyával jelentkeztünk be, akkor is él. 

Ha egy akármilyen kártyát bedugunk, majd kihúzunk, a logoff 
beindul. Vajon miért? 

Fóti Marcell 

marcellfonetacademia.net 


td T. 44 
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Az összes munkatársra kiterjedő identitások kezelése egy vállalaton belül mindig nagy kihívást jelen- 
tett. Napjainkban, az Internet és az elektronikus kereskedelem elterjedésével ez a kihívás megnőtt, 
mert a vállalatok és kormányzatok partnereik és ügyfeleik számára is kénytelenek hozzáférést biztosí- 
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tani belső rendszereikhez és alkalmazásaikhoz. 


Ha az egyre magasabb fokon integrált környezetekben hatéko- 
nyan kívánjuk kezelni a hozzáférési engedélyeket, vállalati 
identitáskezelő rendszer bevezetése válik szükségessé. Az Ac- 
tive Directory, a Microsoft Metadirectory Services, valamint a 
Microsoft többi identitáskezelő megoldásával és termékével a 
rendszergazdák biztonságosan, költséghatékonyan és minimá- 
lis bonyolultság mellett felügyelhetik a felhasználók hozzáféré- 
sét a kritikus vállalati alkalmazásokhoz és adatokhoz. 
Gyakorlatilag minden céges adat elektronikus változata megta- 
lálható a vállalati hálózaton. Éppen emiatt egyre fontosabb és 
nehezebb annak garantálása, hogy csak a jogosultsággal ren- 
delkező felhasználók férhessenek hozzá ezekhez az informáci- 
ókhoz. A vállalatok számára ugyanakkor elengedhetetlen, 
hogy a munkatársak, ügyfelek és üzleti partnerek kényelmesen 
érhessék el a számukra szükséges adatokat. A két alapkövetel- 
mény közti egyensúlyozás az identitáskezelés legnagyobb ki- 
hívása. A témakört körbejárva a rendszergazdák az alábbi kér- 
désekkel szembesülnek: 

A Biztonság: Az alkalmazottak, szerződéses és üzleti 
partnerek miatt módosultak az adatok és az alkalmazá- 
sok elérésével kapcsolatos igények. A vállalatok számá- 
ra létfontosságú, hogy csak az arra felhatalmazott fel- 
használók férhessenek hozzá az érzékeny céges ada- 
tokhoz. 

A A felügyelet bonyolultsága: A korszerű vállalatok szá- 
mos, különféle platformon futó célrendszert használ- 
nak. A felhasználók és a rendszerek számának növeke- 
désével az egységes felhasználói hozzáférési háziren- 
dek kidolgozása is egyre bonyolultabbá válik. 

A Költségcsökkentés: Még az egyszerűbb hozzáférési há- 
zirendek fenntartása is költséges lehet, ha több alkal- 
mazás, rendszer és platform üzemeltetéséről kell gon- 
doskodni, és ezek különálló, saját hozzáférési listát 
használnak. Például 10000 felhasználó jogainak mó- 
dosítása 20 rendszeren legalább 200000 bejegyzés át- 
írását teszi szükségessé. 

Ezeket az identitáskezeléssel kapcsolatos kulcsfontosságú kér- 
déseket lekezelve a vállalkozások nagyobb termelékenységet, 
költségcsökkenést, illetve magasabb fokú üzleti integrációt ér- 
hetnek el. 


Az identitáskezeléssel kapcsolatos biztonsági kihívások 


A biztonságos adatelérés megoldása a hitelesített felhasználók 
számára egyre problémásabb. A legtöbb vállalatnál az egyedi 
alkalmazások és rendszerek saját felhasználói adatbázissal 
vagy címtárral rendelkeznek, ezek alapján ellenőrzik, hogy ki 
használhatja az adott erőforrást. Ahogy a hozzá jogok 
odaítélése egyre inkább decentralizált jellegűvé válik, a biz- 





tonság sérülésére is lényegesen nagyobb esély mutatkozik. 
Például: 

A A távozó alkalmazottak, ügyfelek és üzleti partnerek 
gyakran megőrzik hozzáférésüket a rendszerekhez, 
amit egészen a következő frissítésig, illetve az érvény- 
telenné vált hozzáférések megszüntetéséig használni 
tudnak. 

HA A nem egységes házirendek eredetileg meg nem adott 
hozzáférésre adhatnak módot (pl. humánerőforrás- 
adatbázis). 

A A gyenge hitelesítési adatok, a szegényes vagy nem lé- 
tező jelszóházirendek, illetve a felhasználók által meg- 
jegyzendő nagy számú azonosító és jelszó miatt sebez- 
hetőbbek a rendszerek. 


A felügyelet bonyolultsága 


Ahogy a vállalatok és a kormányzatok egyre több célrendszert 
használnak - például hálózati erőforrás-címtárakat, levelezőki- 
szolgálókat, emberierőforrás-adatbázisokat, hangpostakiszol- 
gálókat, és bérfeldolgozási alkalmazásokat —, egyre összetet- 
tebb feladattá válik a felhasználói jogok kezelése. A vállalat 
egyes részlegei sok esetben különbözőképpen kérvényezik és 
osztják szét az erőforrásokat. Emellett a legtöbb vállalatnál 
minden rendszer saját eszközöket használ a felhasználói fió- 
kok kezelésére. Sokszor külön jelszóra és bejelentkezésre van 
szükség a felhasználók azonosításához. A fenti problémák 
mindegyike hozzájárul az informatikai felügyelet bonyolultsá- 
gának növekedéséhez. Például: 


A Az elosztott és eltérő hitelesítési rendszereket más 
módszerekkel kell felügyelni, kezelni és naplózni. 

mA A címtárak és más identitástárolók sokszorozódása mi- 
att a módosításokat többféle módon, többféle tárolóban 
kell végrehajtani. 

A A felhasználókat kellemetlenül érinti, ha több azonosí- 
tót és jelszót kell észbentartaniuk a különféle alkalma- 
zásokhoz és rendszerekhez. 

TA Ahogy a vállalatok bővítik rendszereiket — hiszen már 
nemcsak a munkatársakat, hanem az ügyfeleket és az 
üzleti partnereket is ki kell szolgálni az Interneten ke- 
resztül —, a problémák csak sokszorozódnak. 


Költségcsökkentés? 


Sok szervezetnél az egyes rendszerek különleges rekordok és 
adatbázis-bejegyzések szigeteiként viselkednek, és felügyele- 
tükről egyedileg kell gondoskodni. Ezek a rendszerek általában 
saját felhasználói identitás-definícióval rendelkeznek (név, be- 
osztás, azonosítók, szerepek és csoporttagságok). Minél na- 


gyobb egy szervezet, annál többféle tárolót találni benne, és 
annál nagyobb költséget és erőfeszítést igényel ezek napraké- 
szen tartása. 


HA A termékmenedzserek, informatikai szakemberek és 
emberierőforrás-vezetők rengeteg időt töltenek űrlapok 
kitöltésével, a felhasználók adatainak bevitelével és 
frissítésével, a fiókok beállításával és az elfelejtett jel- 
szavak módosításával. 

Az új alkalmazottak és szerződéses partnerek gyakran 
napokat várnak arra, hogy hozzáférhessenek a kritikus 
alkalmazásokhoz és információkhoz — eddig tart, míg 
minden rendszergazda beállítja hozzáférésüket. 


Megoldások az identitások kezelésére 


Ha a növekvő számú alkalmazáshoz, rendszerhez, informáci- 
óforráshoz és céghez rendelt hozzáféréseket költséghatékony 
és biztonságos módon akarják kezelni, a vállalatoknak identi- 
táskezelő infrastruktúrát kell kiépíteniük. Az infrastruktúra ki- 
építése átfogó felhasználó- és erőforrás-kezelő rendszer kifej- 
lesztését teszi szükségessé, illetve a biztonság felügyeletéről is 
gondoskodni kell. Az identitáskezelő megoldások alapja több 
összetevőből áll: 

HA Identitástároló címtár, amely biztonságos, hiteles adat- 
forrásként szolgál. 
Az identitás hitelesítése, amellyel ellenőrizhető, hogy a 
felhasználó valóban az-e, akiknek kiadja magát. 
A hitelesítés révén biztosítható, hogy a felhasználók 
hozzáférése az erőforrásokhoz, alkalmazásokhoz, fáj- 
lokhoz és funkciókhoz szabályos és engedélyezett le- 
gyen. 
Platformok közötti együttműködési szolgáltatások, 
amelyek megfelelő időn belül lehetővé teszik a más 
rendszereken és platformokon végrehajtott identitás- 
változások felismerését. 
A jogok biztonsági házirendek szerinti biztosításának 
és visszavonásának kezelése, illetve a kapcsolódó 
rendszerek értesítése felhasználók hozzáadásáról és 
törléséről. 


ma 


Identitástároló 


A felhasználók és az általuk szabályosan igénybe vehető erő- 
források halmazának tárolására általában egy címtárat haszná- 
lunk. A címtárban tárolt információk magukba foglalják az ille- 
tő profiljába tartozó adatokat — pl. név, cím, munkakör -, hoz- 
záférési jogait az egyes erőforrásokhoz, az ezek használatával 
kapcsolatos házirendeket, illetve a biztonsági adatokat, példá- 
ul a jelszavakat. Az identitástároló nemcsak felhasználói ada- 
tokat raktároz, hanem az erőforrások, számítógépek és alkal- 
mazások identitásadatait is, ugyanis a biztonsági házirendek 
ezekre az erőforrásokra is kiterjednek. Az identitásoknak a hi- 
telesítéssel és a jogosultságok kiosztásával való integrálása le- 
hetővé teszi a beléptetést és a címtárral kezelt erőforrások 
használati jogának egyidejű biztosítását. Az Active Directory a 
Microsoft biztonságos, magas rendelkezésre állást nyújtó, 
elosztott központi identitástárolója, amely szorosan együttmű- 
ködik a Windows 2000 operációs rendszerrel. Egyszerre szol- 
gál a felügyelet és a felhasználói fiókok, a hitelesítés, a bizton- 
sági házirendek és a vállalati erőforrások — számítógépek, 
nyomtatók, kiszolgálók — nyilvántartásának központi pontja- 
ként. 


Az Active Directory egyedülálló értéke azon képes- 
sége, hogy a felhasználói identitásokat és a különféle 
erőforrásokhoz való hozzáféréseket különféle rend- 
szereken és platformokon tudja kezelni. Így egy szer- 
vezet az identitásokkal, az azonosítással és a hitele- 
sítéssel kapcsolatos, más alkalmazásokra, rendszerekre és plat- 
formokra is kiterjeszthető adatok megbízható tárolójaként 
használhatja az Active Directoryt. 


- 


Az identitások hitelesítése 


Mély kapcsolat fedezhető fel az Active Directory és az általa 

támogatott Windows 2000 biztonsági modell között. Az Acti- 

ve Directory tárolja a tartománnyal, a hálózattal és a felhasz- 

nálókkal kapcsolatos összes biztonsági házirend adatait. Ez a 

kapcsolat csak az Active Directorynak a Windows 2000 ope- 

rációs rendszer biztonsági inírastruktúrájába való tökéletes in- 
tegrálásával valósítható meg. 

A rendszer erőforrásaihoz való hozzáférések mindegyike hite- 
lesített. A Windows 2000 hitelesítő- 
szolgáltatása — amely az operációs 
rendszer része — egybeépül az Active 


Az Active Directory Directoryval. Ez azt jelenti, hogy a 
bee felhasználók egyetlen jelszó segítsé- 
egybeépülése az gével bármely munkaállomásra beje- 


lentkezhetnek, és ugyanez a jelszó 
biztosítja hozzáférésüket a megfelelő 
erőforrásokhoz is. Az integráció biz- 


operációs rendszerrel 


lehetővé teszi, tosítja a felhasználók eltávolítását is 
az Active Directoryból, ha hozzáféré- 
hogy megbízható sük megszűnik. 
Az Active Directory rendkívül rugal- 
hitelesítési mas, és a legújabb internetes szabvá- 
nyokra épül. Rugalmassága különö- 
adattárolóként sen abból a szempontból érdekes, 
hogy sokféle hitelesítési módszert tá- 
szolgáljon. mogat - így minden vállalat a számá- 


ra szükséges védelmi szintet valósít- 

hatja meg: egyszerű azonosító és jel- 
szóalapú, erősebb, tanúsítványalapú, vagy rendkívül biztonsá- 
gos, intelligens kártyák használatára vagy biometriára alapuló 
hitelesítést használhat. Az Active Directory a Csoportházirend 
szolgáltatással együtt felhasználói- vagy csoportalapon lehető- 
vé teszi a különféle hitelesítési módszerek keverését is. Egy vál- 
lalatnál előfordulhat például, hogy bizonyos felhasználók in- 
telligens kártya, mások pedig csupán felhasználónév és jelszó 
segítségével azonosítják magukat. 
Az Active Directory egybeépülése az operációs rendszerrel le- 
hetővé teszi, hogy megbízható hitelesítési adattárolóként szol- 
gáljon. Az egymással együttműködő, szabványokon alapuló 
hitelesítési eljárások révén a vállalatok más platformokra és 
rendszerekre is kiterjeszthetik az Active Directory hatáskörét. 


Hitelesítés 


A Windows 2000 biztonsági modellje a felhasználó identitása 
alapján minden objektumra egységesen megvalósítja a hozzá- 
férés-vezérlést és a hitelesítést. Minden objektumhoz tartozik 
egy tulajdonos, aki jogokat tud adni az objektumnak. Ha egy 
felhasználó hitelesítése megfelelően lezajlott, a hozzáférés-ve- 
zérlési mechanizmus meghatározza, hogy a felhasználó mely 
objektumokat és hogyan érhet el. 

A hozzáférés-vezérlési listák (Access Control List, ACL) adják 
meg azokat az előírásokat, amelyek alapján az operációs rend- 
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szer gondoskodik egy-egy objektum védelméről. Az 
ACL-alapú megközelítés előnye nyilvánvaló: minden 
objektumot — ami lehet felhasználó, nyomtató, fájl, 
kiszolgáló vagy egyéb hálózati erőforrás — külön ACL 
védhet, az ACL-lel összerendelt identitások tárolását 
és kezelését pedig az Active Directory végzi. Ha egy identitást 
az Active Directory kezel, lehet tisztán Windows-alapú, de 
használható más platformokon is, mindenképpen fog rá vonat- 
kozni egy ACL. Ha egy felhasználó nem tudja megfelelően 
azonosítani önmagát, nem fog hozzáférni az erőforrásokhoz. 
Így az identitás a hitelesítésnél és a jogok megadásakor egyfor- 
mán fontos. Emiatt az Active Directory a vállalati hitelesítés 
központi elemének tekinthető. 


Különböző platformok közti együttműködés 


Az együttműködés alapfeltétele egy olyan metacímtár, amely 
biztosítja a címtár és az egyes szervezetek nagy számú címtá- 
ra, adatbázisa és egyéb tárolója által kezelt információk közöt- 
ti kapcsolatot. Segítségével akkor is egységesen kezelhetők egy 
szervezet felhasználói, ha az adatok több címtárban és felhasz- 
nálói adatbázisban találhatók. 

A metacímtár — mivel szoros kapcsolatban áll az identitástáro- 
lóval — gondoskodik az identitásokkal kapcsolatos változások 
terjesztéséről is. A változások terjesztése automatizálja és egy- 
szerűsíti a felhasználói fiókok és jogok hozzáadását, módosítá- 
sát és visszavonását. A folyamatok automatizálásával csökkent- 
hetők a költségek, és jelentősen növelhető a termelékenység. 
Garantálható a házirendek és eljárások egységes betartása is. A 
visszavonások terjesztése szintén kulcsfontosságú. Amikor egy 
alkalmazott kilép, a változásokat terjesztő rendszer gyorsan és 
egységesen törölni tudja a felhasználói fiókokat, illetve vissza 
tudja vonni a hozzáférési jogokat. A Microsoft olyan együttmű- 
ködési megoldásokat kínál, amelyek kielégítik a vállalatok kü- 
lönféle igényeit. Ezek a termékek a következők: 


TA Microsoft Metadirectory Services (MMS) — lehetővé te- 
szi több rendszeren és platformon tárolt identitásokkal 
kapcsolatos információk integrálását. Az MMS számos 
csatolóval rendelkezik, amelyek többek közt Sun ONE 
Directory Server, Novell NDS és eDirectory, Lotus No- 
tes és cc:Mail rendszerrel integrálják az identitásokkal 
kapcsolatos adatokat. Az MMS támogatja az egyre nép- 
szerűbb internetes adatformátumokat, például az XML 
és a DSML formátumot. Az MMS széles körű együttmű- 
ködési lehetőségek révén növeli az Active Directory ér- 
tékét: integrációs lehetőség különféle identitástárolók- 
kal, az identitásokkal kapcsolatos adatok terjesztése és 
szinkronizálása többféle tárolón keresztül, az identitá- 
sokkal kapcsolatos adatok módosulásának automatikus 
érzékelése és megosztása a rendszerek között. 

A Services for UNIX — UNIX-os felhasználókat, csoporto- 
kat és állomásokat feleltet meg Windows-alapúaknak. 
A UNIX felhasználók és csoportok tehát a Windows fel- 
használókkal és csoportokkal azonos módon kezelhe- 
tők. Ezáltal közös névtér jön létre, és csökken a két kü- 
lönböző névtér és címtár felügyeletéből fakadó többlet- 
terhelés. 

FA Services for Netware — rendkívül rugalmas szolgáltatás, 
amely teljeskörű együttműködési megoldást kínál az 
Active Directory és a Novell NDS és bindery címtárai 
között. Az Active Directory és a Novell rendszerek kö- 
zötti kétirányú szinkronizációval csökkenti az identi- 


táskezelés költségét. A jelszavak szinkronizálását is le- 
hetővé teszi az Active Directory címtárból a Netware 
felé. 

AA Services for Macintosh — a Microsoft Windows 2000 
Server integráns része, lehetővé teszi a Windows és 
Macintosh OS rendszert futtató számítógépek közti fájl- 
és nyomtatómegosztást. Emellett a Windows 2000 Ser- 
ver AppleTalk-útválasztóként is használható. A Services 
for Macintosh tartalmazza a Microsoft User Authenti- 
cation Module-t (MSUAM), amely biztonságos és egy- 
szeri bejelentkezési lehetőséget kínál a Macintosh ügy- 
feleknek a Windows 2000 Servert futtató kiszolgálókra. 

TA Host Integration Server 2000 (HIS) 
— az alkalmazások, adatok és háló- 
zatok integrációjával a hagyomá- 


Az együttműködés nyos állomásokra is kiterjeszti a 
Windows hatókörét. A HIS a Win- 
alapfeltétele egy dows alapú és a hagyományos 
rendszeren is automatikusan hite- 
olyan metacímtár, lesíti a felhasználókat, így egysze- 
rűsödnek a folyamatok. A HIS ké- 
amely biztosítja a pes arra is, hogy az állomás biz- 
tonsági rendszerében végrehajtott 
Címtár és az egyes módosítások nélkül is átültesse a 
Windows alapú felhasználói azo- 
szervezetek nagy nosítót és jelszót a hagyományos 
rendszerbe. 
számú címtára, 
Felügyelet 


adatbázisa és egyéb . Az MMS felügyeleti és adatterjesztési 
lehetőségei mellett a felhasználók és 
számítógépek csoportjaira vonatko- 


zóan a Windows 2000 Csoportházi- 


tárolója által kezelt 


információk közötti rendjével is definiálhatók és betartat- 
hatók a felhasználókra és a számító- 
kapcsolatot. gépekre vonatkozó beállítások. 


A Csoportházirenddel a vállalatok a 
következőkre írhatnak elő házirendet: 
A Rendszerleíró alapú, a Windows 2000 operációs rend- 
szerre, összetevőire és az alkalmazásokra vonatkozó 
házirendek. 
AA Biztonsági beállítások, amelyek a helyi számítógépre, a 
tartományra vagy a hálózatra vonatkoznak. 
A Szoftvertelepítési és karbantartási beállítások, amelyek- 
kel központilag kezelhető a szoftverek telepítése, frissí- 
tése és eltávolítása. 


Megfelelő identitáskezelő megoldást kidolgozva a vállalatok 
egyetlen helyről kezelhetik az összes felhasználói jogot. Így 
megoldhatók a legfontosabb — már említett — identitáskezelés- 
sel kapcsolatos problémák. 

3) 


A IMicrosoít operációs rend- 
szerek biztonsági tényezői 


II. rész — Biztonságos 
hálózati működés 


Az előző cikkben eljutottunk a biztonságos vállalati hálózathasználat alapjaiig. Egy tudatosan bizton- 
ságosra tervezett operációs rendszert ismertünk meg az NT , személyében". Sőt! Van címtárunk és né- 
hány jól tervezett hitelesítési protokollunk, öröklődő jogosultságaink és stabil fájlrendszerünk is. Mi 
kellhet még? PKI, a folyamatok követése (naplózás) és adatfolyamtitkosítás. 


Nyilvános kulcsos architektúra 


Már eddig is számos alkalommal utaltunk a Windows 2000 
nyilvános kulcsú infrastruktúrájára, amelyet rengeteg alkalma- 
zás használ. Most egy kicsit tekintsük át, mit is jelent a PKI a 
Windows környezetben. 

A PKI nem egy szolgáltatás, inkább egy keretrendszer, amely- 
nek elemeit és elemi szolgáltatásait különböző más szolgálta- 
tások igénybe veszik. A Windows 2000-ben az alábbi beépített 
szolgáltatások építenek PKI alapokra: 


H A levelező szoftverek, amelyek az S/MIME szabványt 
alkalmazva aláírt, és/vagy titkosított leveleket készíte- 
nek és továbbítanak. A módszer segítségével meggyő- 
ződhetünk arról, hogy valóban a feladótól kaptunk le- 
velet, azt nem módosították a kézbesítés során, és ille- 
téktelenek nem fértek hozzá a küldemény tartalmához. 
(Letagadhatatlanság, hitelesség, bizalmasság). 

A Biztonságos webhelyek, amelyek képesek a felhaszná- 
lókhoz a tanúsítványuk alapján különféle engedélyeket 
rendelni. 

1 A biztonságos webes kommunikáció, amely SSL és TLS 
protokollok használatával titkosított kapcsolatot épít fel 
az ügyfél és a kiszolgáló között, azonosítja a belépőt a 
tanúsítványa alapján, egyúttal biztosítja a szolgáltatást 
igénybe vevőt, hogy nem egy ,álhelyre" lépett (Kölcsö- 
nös hitelesítés). 

mA Szoftverkód aláírása, amely biztosítja a felhasználót, 
hogy az aláírt szoftver (pl. eszközmeghajtó, makró, 
stb.) megbízható helyről érkezett. 

mA Intelligens kártyás azonosítás, amely a felhasználók ta- 
núsítványát és titkos kulcsát tárolva helyi és távoli beje- 
lentkezést tesz lehetővé. 

TA Az IPSec protokoll, amely képes a felhasználókat vagy 
egyéb objektumokat a kiadott tanúsítvány alapján hite- 
lesíteni egy IPSecre épülő kommunikáció során. 

mA A titkosított állományrendszer (EFS), amely tanúsítvá- 
nyokat használ mind a felhasználók, mind a helyreállí- 
tó ügynökök esetén. 
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user accounts, and so 
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A felsorolás csak az alaprendszerre vonatkozik, amely termé- 
szetesen rugalmasan kiegészíthető más gyártók által forgalma- 
zott megoldásokkal. 

A PKI erőteljesen integrálható a címtárral, kölcsönösen hasz- 
nálják egymás képességeit. A PKI által előállított tanúsítványo- 
kat a címtár segítségével lehet a felhasználókhoz, vagy számí- 
tógépekhez rendelni, és a csoportházirendeket valamint a ta- 
núsítvány-sablonokat is a címtár tartalmazza. Ugyanakkor a 
címtár a PKI tanúsítványokra támaszkodik, amikor kártyás be- 
léptetést használ vagy a Kerberos hitelesítéshez kulcsokat oszt 
ki. A címtár-integráció azonban nem kötelező. A tanúsítvány- 
kiosztó szolgáltatást kétféle módon lehet telepíteni: integrált és 
nem integrált módon. Ha valamely szervezet nem használja az 
Active Directoryt, a nem integrált módot kell választania. 

A Microsoft PKI megoldása jól skálázható, és a címtárral integ- 
rálva komoly versenytársa a hasonló terméket gyártó cégek- 
nek, mivel minden szerverterméknek része ez a komponens. 
Ezzel együtt nem kizárólagos megoldás. Ha egy szervezet úgy 
dönt, hogy a szolgáltatások nem elégítik ki az igényeit, beve- 
zethető más PKI megoldás is, például az E-Trusté. Tekintve, 
hogy egy ilyen rendszer költségeinek nagyobbik része a szer- 
vezet és a folyamatok kialakítása, csak alapos mérlegelés és 
előkészítés után szabad az igényeinknek megfelelő megoldás 
mellett dönteni. 


Naplózás 
A Windows NT és így a Windows 2000 fejlesztői is azt a célt 


tűzték ki, hogy az üzemelés során előforduló eseményeket 
egyetlen közös helyre gyűjtsék. Ezt a helyet eseménynapló 
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(event log) névvel látták el. A törekvés mögött az a 
biztonsági elvárás húzódik meg, hogy bármely ob- 
jektum bármely tevékenysége naplózható, ezáltal 
nyomon követhető legyen. A szándék csak többé-ke- 
vésbé valósult meg. Vannak olyan események, ame- 
lyekről ugyan készül naplóbejegyzés, de nem a központi ese- 
ménynaplóban, hanem egy adott alkalmazás saját állományá- 
ban (pl. az Internet Information Server vagy a fürtszolgáltatás 
az ilyen renitensek közé tarozik). A tervezők kénytelenek vol- 
tak kompromisszumot kötni a naplóbejegyzések és a rendszer 
teljesítménye között. Az elvi lehetőség ugyan adott a teljes 
nyomkövetésre, ha azonban valóban minden eseményt nap- 
lózni szeretnénk, olyan jelentős teljesítménycsökkenéssel kell 
számolni, amely már nem teszi kifizetődővé az információk 
begyűjtését. Ráadásul a megnövekedett bejegyzésszám feldol- 
gozásáról, tárolásáról is gondoskodni kell. 
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Végeredményben a következő megoldás született: az ese- 
ménynaplót három nagy tárolóra osztották: a rendszernaplóba 
kerülnek azok az események, amelyek az operációs rendszer 
alapszolgáltatásaival, eszközkezelőivel és a hardvererőforrása- 
ival kapcsolatosak. A rendszeradminisztrátorok nem módosít- 
hatják ezen tárolón a naplózás részletességét. 

Az alkalmazás naplórészébe kerülnek az operációs rendszer 
kiegészítő szolgáltatásainak (WINS, DHCP stb.) eseményei va- 
lamint a telepített Microsoft vagy harmadik gyártótól származó 
alkalmazások bejegyzései, ha erre a szoftvert egyébként felké- 
szítették (a , Designed for Windows 2000" logó megszerzésé- 
nek egyik feltétele, hogy az alkalmazás teljesítse ezt a kritériu- 
mo. Az események részletességét az adott alkalmazásban le- 
het szabályozni. 

A harmadik tároló a biztonsági napló. Tagkiszolgáló és munka- 
csoportban működő szerverek esetén ez a napló nincs bekap- 
csolva, a rendszer nem rögzít eseményeket. Ha a szerver tarto- 
mányvezérlő, a sikeres és sikertelen hitelesítési eseményeket a 
rendszer itt tárolja. Szemben a másik két naplórésszel, itt kon- 
figurálhatjuk a legrugalmasabban azt, hogy milyen esemé- 


nyeknek maradjon nyoma. Az állományokhoz és a mappák- 
hoz, amelyeket a felhasználók a megosztásokon keresztül ér- 
nek el, napló (audit) beállítások rendelhetők. Tulajdonképpen 
egy objektumra elvégezhető minden egyes művelet sikeressé- 
géről vagy sikertelenségéről készülhet bejegyzés. A naplóbeál- 
lítások — akárcsak a jogosultságok — öröklődnek a mappahie- 
rarchiában (címtár esetén a címtár-hierarchiában), és az örök- 
lődés éppúgy megszakítható vagy újraindítható, ahogy azt ko- 
rábban megszoktuk. 

Az engedélyek (permissions) betartása vagy megszegési kísér- 
lete mellett a jogok (rights) igénybevételéről vagy megszegésé- 
ről is készülhet bejegyzés. A naplórend ezen részét a helyi biz- 
tonsági házirendben vagy tartományi gépek esetén a biztonsá- 
gi csoportházirendben szabályozhatjuk. Minden egyes jog si- 
keres és/vagy sikertelen használatát naplózhatjuk. 

Mód van a naplózás egyéb paramétereinek központi beállítá- 
sára is. Meghatározhatjuk a napló méretét, vagy hogy mennyi 
ideig őrizze a rögzített eseményeket. A biztonsági napló ki- 
emelt fontossága miatt lehetőségünk van arra, hogy amennyi- 
ben betelik a naplózáshoz szükséges hely, a rendszer leállítsa 
magát, és mindaddig ne induljon el, amíg a napló adatait ki 
nem mentettük. Ez természetesen veszélyes beállítás, mert ha 
nem ürítik rendszeresen a naplót, a szerver váratlanul leállhat. 
Ha azonban megfelelő eljárásrendet alkalmazunk, biztosítha- 
tó, hogy egyetlen, biztonsági szempontból kritikus eseményt se 
mulasszunk el. A naplóban található események törléséhez 
rendszeradminisztrátori jogok szükségesek, ám ez szintén sza- 
bályozható. Az egyes bejegyzések külön nem szerkeszthetők, 
csak a teljes napló törölhető, ám az üres napló első bejegyzé- 
se azt rögzíti, hogy a naplót ki és mikor törölte. Ezek az óvin- 
tézkedések azt a célt szolgálják, hogy az üzleti felhasználók ne 
legyenek kiszolgáltatva saját rendszergazdáiknak. 


Hálózati biztonság és titkosítási algoritmusok 


A Windows 2000 operációs rendszer család számos lehető- 
séggel rendelkezik a hálózati forgalom védelmére (titkosítás) 
vagy a hálózati forgalommal szembeni védelemre (NAT, cso- 
magszűrés stb.). Nézzük a képességeket és a felhasználási te- 
rületüket. 

Csomagszűrés. Általában minden TCP/IP implementáció része 
a csomagok elfogadásának vagy elutasításának lehetősége. A 
Windows 2000 alaprendszer csak TCP kapuszámok alapján 
képes csomagok szűrésére. Az ábrán látható módon hálózati 
csatolónként adhatjuk meg, hogy mely kapukat kívánjuk nyit- 
va hagyni. Számos alkalommal ez jó első védelmi vonalat je- 
lent, tűzfalnak és kizárólagos megoldásnak azonban nem al- 
kalmas. Nemcsak azért, mert a támadásokról nem érkezik ri- 
asztás, hanem azért is, mert nem pontosan úgy működik a cso- 
magszűrés, ahogy az egy tűzfalnál megszokott. Egy TCP kap- 
csolat-felvételi kérésére a kiszolgáló , reset connection" csoma- 
got küld, ezzel elárulva, hogy ő tulajdonképpen létezik, csak 
az adott kapu le van zárva. Ezt a védelmet statikusnak nevez- 
zük, mert szituációtól függetlenül változatlan. 
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Címfordítás (Network Address Translation, NAT). A Windows 
2000-ben debütáló szolgáltatás csak részben tekinthető biz- 
tonsági elemnek. Nem történik szűrés, csupán egy adott (álta- 
lában privát) TCP/IP hálózati címtartományt egy másik (több- 
nyire nyilvános) címre fordít le a rendszer. A jelentősége még- 
is nagy, ugyanis a NAT elrejti a belső hálózat struktúráját, és a 
külső szemlélő (behatoló) számára kívülről csak egy vagy né- 
hány állomásnak tűnik. A NAT alapja a Microsoft és más gyár- 
tók tűzfal megoldásának, például az ISA Servernek. 


Távoli hozzáférés (Remote Access). Az egyik legfontosabb — és 
biztonsági szempontból kritikus — szolgáltatás a távoli hozzá- 
férés biztosítása a felhasználóknak. A távoli hozzáférés bizto- 
sítja, hogy munkatársaink bárhol és bármikor képesek legye- 
nek hozzáférni a helyi hálózatokban tárolt információkhoz. A 
biztonságos távoli hozzáférést az alábbi fejlesztések szolgálják: 


A Biztonságos felhasználóazonosítás: A rendszer lehető- 
vé teszi a felhasználót azonosító adatok titkosított cse- 
réjét. Számos szabvány áll rendelkezésre ehhez, töb- 
bek között az Extensible Authentication Protocol (EAP), 
a Microsoft-féle Challenge Handshake Authentication 
Protocol (MS-CHAP) 1-es és 2-es verziója, a Challenge 
Handshake Authentication Protocol (CHAP) valamint a 
Shiva Password Authentication Protocol (SPAP). 

HA Kölcsönös azonosítás: Az egyoldalú azonosítás mellett 
beállíthatunk kölcsönös, tehát mind az ügyfél, mind a 
szerver oldaláról kikényszerített azonosítást is. Ezt az 
EAP-Transport Level Security (EAP-TLS) protokoll vagy 
az MS-CHAP 2-es verzió biztosíthatja. 

HI Adattitkosítás: Ha nem elégséges csak a hitelesítési in- 
formáció titkosítása, hanem a teljes adatforgalmat kell 
védenünk, erre is van mód. Az EAP-TLS és az MS- 
CHAP2 protokollok kiegészítő beállítása lehet az adat- 
folyam titkosítás. A Windows 95 és az utána kibocsá- 
tott Microsoft rendszerek ismerik a Microsoft Point-to- 
Point Encryption Protocol (MPPE) szabványt. Az MPPE 
RSA RCA titkosítást használ 40, 56 vagy 128 bites titkos 
kulccsal. Az MPPE kulcsok az MS-CHAP vagy az EAP- 
TLS hitelesítési folyamat során generálódnak. 

A Visszahívás: Egy egyszerű biztonsági beállítás. Lénye- 
ge, hogy a hitelesítés után a szerver bontja a kapcsola- 
tot, és egy előre meghatározott számot tárcsáz. A kap- 
csolat bármely telefonszámról kezdeményezhető, de 
csak egyetlen számot hív vissza a rendszer, tehát csak 
itt használható. 

TA Hívó-fél azonosítás: Ha a telekommunikációs rend- 
szerelemek lehetővé teszik, beállítható, hogy a betár- 





csázást csak egy adott számról lehessen kez- 
deményezni. Ez egy ritkán használt szolgálta- 
tás, a visszahívásnál annyival szigorúbb, 
hogy már a kezdeményezés sem történhet 
akárhonnan. 

JA Fiókzárolás távoli hozzáférés esetén is: Különösen 
VPN kapcsolat során fontos, hogy bizonyos számú pró- 
bálkozás után a rendszer kizárja a bejelentkezni igyek- 
vőt, feltételezve, hogy illetéktelenül próbál valaki be- 
hatolni. A rendszergazdák beállíthatják, hogy hány si- 
kertelen próbálkozás után zárja ki a rendszer a felhasz- 
nálót, továbbá azt is, hogy mennyi idő után kapcsolja 
vissza a kizárt fiókot. 


A rugalmasabb konfigurálás elősegítése érdekében a Windows 
2000 a távoli hozzáférések szabályozására is tartalmaz házi- 
rendet. Ennek segítségével olyan szabályokat definiálhatunk, 
hogy , A pénzügyi csoport reggel nyolc és délután négy között 
nem tárcsázhat be, egyébként pedig a betárcsázás után csak a 
levelező szerverrel kommunikálhat". A szervezet működését 
megismerve számos olyan szabályt lehet létrehozni, amely 
csökkentheti az esetleges támadások mozgásterét. 


Virtuális magánhálózat (Virtual Private Network, VPN). A be- 
tárcsázás helyett egyre gyakoribb a VPN kapcsolatok kialakítá- 
sa. A Windows 2000 ugyanazzal a komponenssel (Routing and 
Remote Access) oldja meg mindkét igényt, így a biztonsági 
szolgáltatások is nagyon hasonlóak, sokszor ugyanazok. A 
VPN azonban kiegészül három olyan szabvánnyal, amelyet a 
RAS nem ismer. Ezek a PPTP, az L2TP és az IPSec. 


VPN connection 





Intranet 


A PPTP (Point to Point Tunneling Protocol) a Windows 95-től 
kezdve valamennyi Microsoft operációs rendszer által ismert 
szabvány. MPPE módszert használ a VPN csatorna kialakításá- 
ra. MS-CHAPv2-vel és erős jelszóval biztonságos kapcsolat 
építhető fel vele. Könnyű telepíteni és konfigurálni, integrálha- 
tó smart-kártyás hitelesítési módszerrel (EAP-TLS segítségével) 
és együttműködik a NAT szolgáltatással. 

Az L2TP (Layer 2 Tunneling Protocol) az IPSec (Internet Proto- 
col Security) szabvánnyal együtt képes a PPTP-hez hasonló 
szolgáltatást nyújtani. Alkalmazásuk esetén lehetőség van a fel- 
használó mellett a számítógép azonosítására is, továbbá min- 
den egyes csomagot ellenőriz a rendszer integritása és hiteles- 
sége szempontjából. A kétségtelen biztonsági előnyökkel 
szemben azonban számos nehézségbe ütközhetünk egy ilyen 
VPN rendszer kialakításakor. Az LZTP/IPSec feltételezi egy PKI 
infrastruktúra előzetes felállítását, amely kis szervezetek szá- 
mára költséges lehet. A Windows 2000-ben található imple- 
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" Biztonságos hálózati működés / 


A Microsoft operációs rendszerek biztonsági tényezői 
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mentáció nem működik együtt a NAT szolgáltatással, 
mert a NAT lecseréli a csomag IP címét, ami az integ- 
ritás megsértését jelenti. A teljes igazsághoz hozzá- 
tartozik, hogy mind a NAT, mind az IPSec egy Inter- 
netes szabvány, amelyet a Microsoft pontosan követ. 
Az inkompatibilitás tehát a szabványok összeférhetetlenségé- 
ből adódik, és nem szoftvercég hibája. (A Windows .Net Ser- 
ver VPN implementációját felkészítik a NAT-tal való együttmű- 
ködésre egy új szabványtervezetet figyelembe véve.) További 
probléma, hogy az LZTP/IPSec együttest csak a Windows 2000 
és Windows XP ügyfelek ismerik. A Microsoft 2002 augusztu- 
sában kiadott egy , Microsoft LZTP/IPSec VPN Client" szoftvert, 
amely a Windows 98, Windows Millennium Edition és Win- 
dows NT 4.0 rendszerekhez nyújt megoldást. 


Az IPSec. Az Internet Security Protocol nem csak a VPN meg- 
oldásoknál használható. Egy olyan nyílt szabvány implementá- 
ciójáról van szó, amely két célt tűzött ki maga elé: védeni az 
IP csomagokat, és védelmet nyújtani a hálózat elleni támadá- 
sokkal szemben. Az IPSec a következő támadásokkal szemben 
képes hatékony védelmet nyújtani: 


A Hallgatózás (sniffing): Az IPSec az IP csomagokat tit- 
kosítja, tartalmuk harmadik fél számára nem értelmez- 
hető. 

A Adatmódosítás: Az IPSec kriptografikus szabványok 
szerint előállított kulcsokat használ, amelyeket csak a 
kommunikációban résztvevő számítógépek birtokol- 
nak. Ezen kulcsok segítségével titkosítja, és digitális el- 
lenőrzőösszeggel látja el az IP csomagokat, így azonnal 
kiderül, ha bármilyen módosítási kísérlet történt. 

AA Hamis azonosság, szolgáltatás-túlterhelés: Az IPSec 
segítségével lehetséges olyan kommunikáció, amely- 
ben csak előzetesen azonosított és megbízható felek 
vesznek részt. 

A Man-in-the-Middle: A kölcsönös azonosítás kizárja, 
hogy egy harmadik fél a szerver felé ügyfélnek, az ügy- 
fél felé pedig szervernek adja ki magát. 


Az IPSec nyílt szabvány, ami nem jelenti azt, hogy a Microsoft 
ne adhatna többletszolgáltatást a megoldásához. Az IPSec a 
Windows 2000 tartományi modelljét használja, az IPSec házi- 
rend pedig Kerberos v5 hitelesítést alkalmaz, hogy azonosítsa 
a kommunikációban résztvevő számítógépeket. A tartomány- 
modell segít az IPSec alapú kommunikáció kialakításában. 
Ahogy azt már korábban más szolgáltatásoknál is megszokhat- 
tuk, az IPSecre vonatkozóan is kialakíthatunk házirendeket, 
amelyek azután a tartomány minden számítógépén (amely a 
házirendet értelmezi) érvényre jutnak. Nem kell tehát minden 
egyes gépet külön-külön beállítani. 

Szerencsés módon az IPSec ,átlátszó" szolgáltatás, — nincs 
szükség az alkalmazások újraírására. A felsőbb szintű alkalma- 
zások tulajdonképpen nem is érzékelik, hogy az IPSec műkö- 
dik. Minden kommunikáció, amely TCP/IP alapú, biztonságo- 
sabbá tehető vele. 

A Windows 2000 rendszerben az Internet Key Exchange (/KE) 
dinamikusan cseréli és kezeli a titkosító kulcsokat a kommuni- 
káló felek között. 

Az IPSec integrálható a PKI infrastruktúrába, a hitelesítéskor 
használhatók a kiadott tanúsítványok. Így azokkal a számítógé- 
pekkel is biztonságosan lehet kommunikálni, amelyek nem 
tagjai egy közös erdőnek, de megfelelő tanúsítvánnyal rendel- 
keznek. Ha azonban nincs PKI, az sem probléma, mert be le- 
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het állítani egy előre megadott közös jelszót, amely a hitelesí- 
tés alapjául szolgál. Természetesen ez elviekben kevésbé biz- 
tonságos, hiszen meg kell oldani, hogy a közös jelszó egy biz- 
tonságos csatornán keresztül kerüljön a két félhez. 


IPSEC , tűzfal". Az IPSec szabvány alkalmazásából , adódik" 
egy lehetőség a hálózati csatolókon zajló kommunikáció sza- 
bályozására. Lényegében egyfajta csomagszűrést lehet megva- 
lósítani. A korábban ismertetett megoldáshoz képest azonban 
további előnyök is jelentkeznek. Egy-egy IP címre és hálózati 
csatolóra külön megadható szabályokról van szó. A beállítás 
nem igényel újraindítást. A lezárt kapukra érkező csomagok el- 
dobásával a szerver , rejti magát", — viselkedése megegyezik a 
valódi csomagszűréssel. 

Előnyös tulajdonságai ellenére ez a megoldás sem tekinthető 
tűzfalnak. Nem dinamikus, nem kapunk riasztást támadás ese- 
tén, és nem integrálható a NAT-tal. Ennek ellenére a módszert 
lehet ajánlani, mert jó alapot nyújt az egyéb megoldások mel- 
lett. 


A beépített alkalmazások biztonsága 


A Windows 2000 rengeteg beépített alkalmazást tartalmaz, 
amelyek részben az operációs rendszerre támaszkodva saját 
biztonsági funkciókkal is rendelkeznek. Röviden tekintsük át, 
melyek ezek az alkalmazások, és milyen védelmi képességek- 
kel ruházták fel őket. 


Internet Information Server (IIS) 


Az Internet Information Server (/IS) a Windows 2000 beépített 
webszervere. Tulajdonképpen három fő szolgáltatása van: a 
web (HTTP), a levél (SMTP) és a hírlevél (NNTP). Mi most tág 
értelemben használjuk az IIS kifejezést, mindhárom szolgálta- 
tást beleértve. 

Az IIS biztonsági alrendszerét szorosan integrálták a Windows 
2000-hez. Képes titkosított csatorna kiépítésre a webes ügyfe- 
lekkel a HTTPS és a TLS protokollokat használva. A webszer- 
veren keresztüli állomány-hozzáféréseket a Windows 2000 en- 
gedélyrendszerével szabályozhatjuk. 

Az IIS többféle módon képes az ügyfelek hitelesítésére. A nyil- 
vános adatokhoz elégséges azonosítatlan hozzáférés. Ekkor az 
ügyfél nem azonosítja magát, a webszerver pedig az 
IUSR. cszervernév: elnevezésű felhasználóhoz tartozó kon- 
textusban jár el. A basic hitelesítésnél már azonosítja a fel- 
használót, de az identifikációhoz szükséges jelszó kódolatla- 
nul halad át a hálózaton. Ha a teljes adatfolyamot előzőleg 
nem titkosítottuk, ez a módszer nem biztonságos. A harmadik 
módszer az integrált Windows hitelesítés, melynek előnye az 
előző eljáráshoz képest a biztonságos jelszóátvitel, hátránya 
azonban, hogy csak az Internet Explorer böngésző alkalmas a 
hitelesítés elvégzésére. További aggály a módszerrel szemben, 
hogy gyenge jelszó és szofisztikált támadás esetén mégiscsak 
mód van a jelszó illetéktelen megszerzésére. A negyedik mód- 
szer megoldást jelenthet a problémára, ekkor ugyanis az elő- 
re kiosztott felhasználói tanúsítvány segítségével azonosítja a 
böngésző a szerver felé a felhasználót. Bár messzemenően ez 
a legbiztonságosabb eljárás, csak korlátozottan használható, 
mert feltételezi a nyilvános kulcsú infrastruktúra meglétét. 

Az IIS-ben szabályozhatjuk, hogy a szerveroldali kódokat a 
felhasználók végrehajthatják-e, és ha igen, milyen feltételek 
mellett. Ez minden egyes virtuális könyvtár esetén külön-kü- 
lön megtehető. Meglévő PKI infrastruktúrát feltételezve az IIS 
ellátható szerveroldali tanúsítvánnyal, amely segítségével az 
ügyfelek meggyőződhetnek arról, hogy a kiszolgáló nem egy 


imposztor. A hitelesítéssel együtt így megvalósulhat a kommu- 
nikációban résztvevő felek kölcsönös azonosítása. 

A számos biztonsági funkció mellett is az egyik ,leglyuka- 
sabb" Microsoft alkalmazás az IIS. Profi hackerek és jószándé- 
kú hibakeresők gyakran fedeznek fel olyan, általában progra- 
mozás-technikai hibából adódó biztonsági réseket, amelyek 
komolyan veszélyeztethetik a rendszerre bízott adatokat. A 
teljes igazsághoz az is hozzátartozik, hogy ez az az alkalma- 
zás, amely a ,nyílt Interneten", a frontvonalban van, tehát a 
leginkább kitett mindenféle próbálkozásnak. 

A helyzet más szempontból is súlyos. A Microsoft következe- 
tes fejlesztési politikájának eredménye az, hogy az azonos 
funkcionalitású komponenseket csak egyszer fejleszti ki, és in- 
kább függőségeket teremt egymástól egyébként , függetlenül" 
fejlesztett alkalmazások között. Az IIS telepítése szükséges 
előfeltétele az Exchange 2000 telepítésének, mert az Exchan- 
ge 2000 az IIS számos szolgáltatását (SMTP, NNTP, web ala- 
pú hozzáférés, Metastore stb.) használja. Az IIS sebezhetősé- 
ge tehát egyben a rá épülő alkalmazások sebezhetőségét is je- 
lentheti. 


Dynamic Host Configuration Protocol (DHCP) 


A Dynamic Host Configuration Protocol szabvány majdnem 
kizárólag szórt üzenetcsomagokkal dolgozik a harmadik és 
negyedik hálózati rétegben. Az IPSec módszert nem számítva 
nehéz biztonságossá tenni ezt a szolgáltatást. Pedig nagy 
szükség lenne rá, mert egy elindított, de véletlenül vagy szán- 
dékosan rosszul konfigurált szerver megakadályozhatja, hogy 
a számítógépek képesek legyenek bármiféle kommunikációra. 
Egy Windows 2000 tartománystruktúrában úgy próbálják ele- 
jét venni kalóz DHCP szerverek megjelenésének, hogy köte- 
lezővé teszik a tartományban működő valamennyi DHCP 
szerver működésének engedélyezését. Ha ilyen engedéllyel 
nem rendelkezik a szerver, akkor a szolgáltatás automatikusan 
leáll. Az engedély megadását enterprise administrator jogkör- 
höz rendelték. A DHCP szolgáltatás ,szabadidejében" kalóz 
DHCP szervereket keres, és ha talál ilyet, naplóbejegyzés for- 
májában értesíti az adminisztrátorokat. Bár mindenféle 
DHCP-n alapuló támadásra ez nem jelent megoldást, mégis 
nagy segítség a hálózat-felügyeletben. 


Domain Name System (DNS$) 


A Windows 2000 fejlesztői a címtár struktúráját erőteljesen in- 
tegrálták a DNS névfeloldási szabványhoz. DNS nélkül nincs 
Active Directory sem, másképp fogalmazva, a DNS szolgálta- 


tás elleni támadás a címtár, és így minden címtárral 
integrált alkalmazás működését teszi lehetetlenné. 
Az operációs rendszerben implementált DNS meg- 
oldás teljes egészében szabványos, de a programter- 
vezők néhány speciális funkcióval is kiegészítették a 
névfeloldást. A funkciók egy része a DNS biztonságát hivatott 
növelni. Az egyik ilyen funkció a zónák Active Directoryban 
való tárolási lehetősége (Active Directory Integrated DNS Zo- 
ne). Egy ilyen integrált zóna írható és olvasható is, ezáltal 
megszűnik a DNS szabványból fakadó gyenge pont, miszerint 
egy zóna fájlnak csak egyetlen írható példánya van. Ráadásul 
a címtárban már megismert jogosultságrendszer kiterjeszthe- 
tővé válik a zónákra is, így azok adminisztrációját szigorú mó- 
don szabályozhatjuk. Egy zóna bevonása a címtárba azt is je- 
lenti, hogy a zóna replikációja a címtár replikációs infrastruk- 
túráját fogja használni, amely minden esetben redundáns, te- 
hát a működés szempontjából biztonságos. Ha pedig ez a rep- 
likáció nem megbízható, vagy nem ellenőrzött adatcsatornán 
történik, akkor a címtárba épített védelmi képességeket az in- 
tegrált zónák is élvezik. 

A zónák frissítése automatikusan történhet, mert erre a DNS 
szervert felkészítették. Beállíthatjuk azonban, hogy csak olyan 
számítógépek írissíthessék a zónát, amelyek azonosítása ko- 
rábban már megtörtént, tehát illetéktelen zónafrissítés kizár- 
ható. Ennek a funkciónak azonban van tervezési hibája: ha 
egy új altartományt akarunk létrehozni, akkor a DNS zóna egy 
olyan tartomány tartományvezérlőjét keresi, amely még nem 
létezik, hisz épp most készül el. A hitelesítés sikertelensége 
így a zónaífrissítést is meghiúsítja, végeredményben nem jön 
létre az új altartomány. Jelenleg tehát a biztonságos zónaíris- 
sítés nem minden esetben használható szolgáltatás. 


Fürtszolgáltatás (Cluster) 


Némi biztonsági funkciót a nagy rendelkezésre állást biztosí- 
tó fürtszolgáltatásba is beépítettek. A fürtadminisztrátor alkal- 
mazást ugyan bárki elindíthatja, de az erőforrások menedzse- 
lését csak az végezheti el, akinek erre külön joga van. A biz- 
tonsági funkciók azonban nem túl részletesek, nincs mód erő- 
forrásonként engedélyek kiosztására, sőt, ezt még csoporton- 
ként sem tehetjük meg, kizárólag a teljes fürtre vonatkozó jo- 
gokat definiálhatunk. 


Lepenye Tamás, MCSE 2000 
lepenyetőmal.hu 
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, — Dupla KU 


Hiberfil.sys 


K: Windows XP-t telepítettem és csakhamar elfogyott a hely a 
rendszerpartíción. Megvizsgáltam a rejtett fájlokat és találtam 
a gyökérben egy hiberfil.sys fájlt. Gondolom ez a hibernálás- 
hoz kell, de én sosem használtam ezt a funkciót. Hogy tud- 
nám eltávolítani a fájlt? Letörölni nem tudtam! 


V: Valóban, a hiberfil.sys a hibernáláshoz használatos, a gép 
hibernálásakor ebbe a fájlba menti el a teljes memóriatartalmat 
a Windows XP. Ezért aztán a hiberfil.sys mérete mindig meg- 
egyezik a fizikai memória méretével. Ha ezt a helyet szeret- 
nénk felszabadítani, ki kell kapcsolni a hibernálás funkciót, 
amely alapértelmezésben be van kapcsolva: 

Control Panel 2 Energiagazdálkodás (Power Options) 2 A Hi- 
bernálás vagy Hibernate tulajdonságlapon ki kell kapcsolni a 
hibernálást. 


Az OK megnyomása után a hiberfil.sys fájl el fog tűnni a rend- 
szerpartícióról és felszabadul a hely. 


Mellékletek mentése Outlook Expressből 


K: Outlook Express 6-os verziója nem engedi a mellékletek tar- 
talmát lementeni. Eddig nem volt ezzel probléma, csak mióta 
a 6-os verziót használom. Hogy tudnám menteni mégis a mel- 
lékleteket? 


V: az Outloook Express 6-os verziója biztonsági okokból alap- 
értelmezésben nem engedi lementeni a mellékleteket, ezzel 
akadályozva a vírusok terjedését. A következő módon lehet 
kikapcsolni ezt a védelmet: 

Outlook Express Eszközök (Tools) menü 2 Beállítások (Opti- 
ons) 2 Biztonság (Security) tulajdonságlap. 

Itt ki kell venni a pipát a képen bekeretezett beállítás elől. 


General ] Read] Receipts ] Send  ] Compose ]  Signatures ] 
Speling Security] Connection Maintenance 
Virus Protection 
a Select the Internet Explorer security 20ne to use: 
ég € intemet secure, but more functk 
( Restricted sites zone (More secure) 


[7 Wam me when other-applications teto. send mail as me. 
AT Donat allow attachments to be saved or opened that could 
7 botentiallv be a virus. ez 





Secure Mail 
Oan Digital IDs (also called certificates) are special 


dacumanko Haat allami unit ha nzawa nazar idősntiha in 


Tell me more... 


E A mellékletek mentésének engedélyezése 
Az OK után a beállítás azonnal érvényre jut. 


Outlook Express, csupán hírolvasó ügyfél (NNTP kliens) 


K: Outlook 2000-et használok levelezőprogramként, és Out- 
look Expresst hírolvasóként (vagyis NNTP kliensként). Nincs 


szükségem az Outlook Express levelező szolgáltatására, csu- 
pán hírolvasóként szeretném használni. Van erre valami meg- 
oldás? 


V: Meg lehet szabadulni a levelező kliens funkcióktól, ehhez 
csupán annyit kell tenni, hogy a /outnews kapcsolóval kell in- 
dítani az Outlook Expresst. 

A Start Menü Futtatás ablakából az msimm /outnews pa- 
ranccsal indíthatjuk: nem lesz Inbox és az Accounts menüből 
eltűnik a Mail menüpont. 

Természetesen a parancsikont is megváltoztathatjuk, ilyenkor a 
parancs végéhez az idézőjeleken kívülre kell írni a /outnews 
kapcsolót, például így: 


Outlook Express Properties el xi 


General  Shortcut ] Compatibility ] Security ] 
sa] Dullaok Express 





Targettype: Application 
Target location: Outlook Express 


Iarget [ee FilesXüutlook Expresstmsimn.exe" /outnews 7 








[/HOMEDRIVEZZHOMEPATHZ 


2 OF indítása hírolvasóként 





Start in: 


Windows 2000 DNS Forwarder 


K: Frissen telepítettem Windows 2000 Active Directoryt az 
első tartományvezérlővel, a DNS Active Directory-integrált, 
mindent maga csinált. A DHCP-n beállítottam, hogy a munka- 
állomások ezt a szervert használják DNS-ként, innentől kezd- 
ve a klienseken nem működik az Internetes névfeloldás. Gon- 
doltam beállítok forwardert a DNS szervernek, de ezt meg a 
Windows 2000 DNS nem engedte. Most akkor mit lehet tenni, 
vagy Internet vagy Windows 2000 AD? Mind a kettő kellene! 


V: Az Active Directory telepítő varázsló, ha nincs közvetlen in- 
ternetes kapcsolat, létrehoz egy root zónát a DNS-ben a nor- 
mál zóna mellett. Egyszerűen le kell törölni a . (pontjnevű zó- 
nát a zónák listájából, ezután már be lehet állítani a forwardert. 


Internet Explorer AutoComplete 


K: Szeretném minden felhasználó esetén letiltani, hogy az In- 
ternet Explorer megjegyezze a beírt jelszavakat. Azt is szeret- 
ném megakadályozni, hogy ezt egyáltalán felajánlja a felhasz- 
nálóknak. A környezet igen vegyes, Active Directory ugyan 
már működik, de a Windows 2000-ek és XP-k mellett még 
vannak Windows NT 4.0 kliensek is. Remélem, van lehetőség 
központilag tiltani ezt a , fícsört". 


V: Az alábbi képen az látható, hogy mindezt hogyan tudjuk til- 
tani az Internet Explorer beállításai közt: 


ZIxI 


SutoComplete lists possible matches from entries youve 
typed before. 








mm ÍV Prompt me to save password 
zek a AZÁS d OL ezzéen Ű 









Clear öutoComplete history 


Clear Forms l Clear Passwords ! 


To clear Web address entries, on the General tab in 
Internet Options, click Clear History. 





B Internet Explorer AutoComplete kikapcsolása 


Ez az ablak az Internet Explorer Tools 2 Intenet Options panel 
2 Content tulajdonságlap 2 AutoComplete gomb mögött bú- 
jik meg. Jól el van rejtve. 

Ha kivesszük a pipát, nem fogja felajánlani a felhasználóknak 
a beírt neveket és jelszavakat, viszont a már beírtakat nem fog- 
ja kitörölni. A korábban beírt jelszavakat és neveket csak ma- 
nuálisan lehet kitörölni. Legegyszerűbben az egész profil újra- 
generálásával lehet talán megszabadulni tőle. 

Ez eddig nyilván nem az automatikus beállítás. Az egyes ope- 
rációs rendszerekre és böngészőverziókra más-más módszer 
használható. 

Windows XP és Windows 2000-es ügyfelek esetén viszonylag 
egyszerű a megoldás. A csoportos házirendben tudjuk szabá- 
lyozni az Internet Explorert, hogy ne ajánlja fel a nevek és jel- 
szavak megjegyzését. A csoportos házirendek közt a User 
Configuration 2 Administrative Templates 2 Windows Com- 
ponents 2 Internet Explorer alatt található két beállítás amely 
ezt szabályozza: 


HA Disable Autocomplete for Forms — ha ezt Enabled stá- 
tuszba állítjuk, az IE nem fogja kiegészíteni az űrlapok- 
ban a neveket és a hozzá tartozó jelszavakat. (Ez a felső 
pipa a kép bekeretezett részén) 

TH Do not allow AutoComplete to save passwords — ha ezt 
is tiltjuk, az Internet Explorer nem fogja felajánlani a 
jelszavak mentését. (ez az alsó pipa a kép bekeretezett 
részén) 


Ha ezeket a beállításokat a Default Domain házirendben állít- 
juk be, nagy valószínűséggel kivétel nélkül mindenkire hatni 
fog a beállítás. Természetesen, ha csak bizonyos felhasználók- 
ra szeretnénk ezt a tiltást beállítani, külön szervezeti egységet 
képzünk nekik — vagy csoporttagság alapján is szabályozhatjuk 
a házirendet. 

Egyébként a beállítás az Internet Explorer 5.01-es verziójától 
kezdve változatlan. 


Windows NT 4.0 esetén kicsit más a megoldás, ilyen- 
kor talán közvetlenül a regisztrációs adatbázis módo- 
sításával legegyszerűbb ezt a beállítást kierőszakolni. 
Ehhez létre kell hozni a következő .reg kiterjesztésű 
fájlt. 

REGEDIT4 


IHKEY. CURRENT. USERASoftwarelMicrosoftNInternet 
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"FormSuggest PW Ask"-"no" 


"FormSuggest Passwords"-"no" 


Ezt a fájlt mondjuk a login scriptből lehet a felhasználónak el- 
juttatni (a regedit /s cfájl név: paranccsal). Kérdés, hogyan tud- 
juk megtiltani a felhasználóknak, hogy ezt a beállítást kézzel 
visszaváltoztassák. Ehhez az Internet Explorer Administration 
Kit-ből kinyerhető .adm fájlra lesz szükségünk, amelynek segít- 
ségével szabályozhatjuk, hogy mit tud átállítani a felhasználó 
az Internet Explorer beállításai közt. 


Windows XP és a Network Monitor driver 


K: Szeretném Network Monitorozni az egyik Windows XP-t a 
hálózatunkon, ehhez kellene Network Monitor agentet telepí- 
tenem, de sehol nem találom. Windows 2000 esetén fel lehe- 
tett telepíteni, a Windows 2000 része volt. Windows XP-ben 
már nincs ilyen? 


V: A Windows XP már nem tartalmazza a Network Monitor dri- 
vert, de külön fel lehet telepíteni. A telepítő CD-n található 
Support Tools része a netcap.exe program, ami többek közt a 
Windows 2000 Network Monitor driver megfelelője is. 

A Netcap egy parancssori progam, amely a telepítő CD-n a 
SupportVTools könyvtárban található support.cab fájlból kibá- 
nyászható. 





:Nnetcap)netcap /? 


Microsoft Netvork Monitor capture utility 

Usagor NetCap.exe [/B:R3 [/T CIyye) (Buffor2 ClexOffsot) CHexPattern)l 
UF:Cfilterfile.cf21 [/C:rCcapture file2) [/N:t) 

U/L:HH:MM:SS] [/TCF:CFolder Name2) 


Exanple: NetCap /B:28 /N:2 /T BP 188 Ba ff1£€ /F:d:XMIPFilter.CF 





a A netcap.exe kapcsolói 


Első futtatáskor kérdés nélkül telepíti a Network Monitor dri- 
vert, ami elengedhetetlen a monitorozáshoz. Ezen túlmenően 
parancssorból monitorozhatunk is vele az adott gépről, tehát 
nem csak kliensként tud működni. Netcap /? segítségével kap- 
hatjuk meg a használható kapcsolókat. Jó szórakozást! 
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NETALADEMIR MESTERÜRLUSUK 


2003. Tavaszi program 


A tavaszi előadások vendégelőadói értékes ajándékokkal is meglepik a kedves résztvevőket! 
Kérjük, hozza magával a korábban kiosztott kedvezményes jegyet! 


2003. március 27. 13:45 - 1 


13:35 — 14:00 
14:00 — 15:00 


15:00 — 16:00 


16:00 — 16:20 
16:20 -— 17:20 
17:20 - 18:00 





Regisztráció 
Bevezetés a hálózati forgalom elemzésébe 
Minél összetettebb egy vállalati hálózat, minél többféle szolgáltatást futtatunk, annál furcsább hibajelen- 
ségeknek lehetünk időnként tanúi. A hálózati forgalom elemzésével olyan hibák felderítésére is lehetőség 
nyílik, amelyekről semmit sem mond az Eseménynapló! 
(Fóti Marcell) 
(Kapcsolódó tanfolyamaink: NetMon Workshop, TCP/IP Workshop) 


A nyílt kulcsú technológia építőkockái 
A digitális aláírási törvény megjelenésével egyre több vállalat fordul érdeklődéssel a nyílt kulcsú techno- 
lógiák felé. Mi kell ahhoz, hogy elérhetővé váljon számunkra a PKI adta sok-sok lehetőség? 
(Vendégelőadó: NetLock Kft.) 
(Kapcsolódó tanfolyamaink: PKI Workshop) 


Kávészünet 


Nyílt kulcsú architektúra a Windowsban 
A PKI felhasználási területei a titkosított hálózati kommunikációtól a digitális aláíráson keresztül a felhasz- 
náló-azonosításig terjednek. Kiszolgálóoldalon többek között a RAS, VPN, IPSec, és IIS, felhasználói 
oldalon a Smart Card Logon, dokumentumok aláírása, S/MIME a témaválaszték. A műsorváltoztatás jogát 
az újonnan megjelenő szolgáltatások miatt fenntartjuk! 
(Fülöp Miklós) 
(Kapcsolódó tanfolyamaink: 2150 - Windowsos hálózatok biztonsága, 2159, ISA Server) 
Gyakorlat: Felhasználói és kiszolgálóoldali PKI-gyakorlatok 
Hiteles NetLock tanúsítványpár elektronikus aláíráshoz és titkosításhoz. A kulcstároló 
eszközök a helyszínen megvásárolhatók. 


2003. május 29. 13:45 - 18:00 


13:35 — 14:00 
14:00 -— 15:00 
15:00 -— 16:00 
16:00 - 16:20 


16:20 - 17:20 


Regisztráció 
Az elektronikus levelezés védelmének lehetőségei Exchange Serveren 
Az elektronikus levelezés áldás és átok egyben. A veszélyes leveleket nem szabad a felhasználókig eljuttat- 
ni. Ennek eszköze lehet az Outlook-ügyfelekhez készített központi korlátozóeszköz, vagy egy víruskereső. 
(Fóti Marcell) 
(Kapcsolódó tanfolyamaink: 1572 - Exchange Server üzemeltetése) 


SOAP (Előadó: Soczó Zsolt) 
A webszolgáltatások alapjait a SOAP-szabvány rakta le. Az előadásban áttekintjük a SOAP történelmi 
gyökerét, és az XML-technológiákon keresztül megnézzük gyakorlati felhasználását is. 
(Soczó Zsolt) 
(Kapcsolódó tanfolyamaink: .NET fejlesztési tanfolyamok) 


Kávészünet 


A Windows rendszerek támadható, és védelmi felületei 
A vírusvédelem egyik faktora nyilván a jó, friss víruskereső program. A másik faktor az okos felhasználó, 
illetve az okos rendszergazda. Ebben az előadásban megismerkedünk a vírusok által használt támadási 
trükkökkel, így soha többé nem fogunk Administratorként levelezni... 
(Vendégelőadó: VirusBuster Kft.) 
(Kapcsolódó tanfolyamaink: 2150 - Windowsos hálózatok biztonsága, 2159, ISA Server) 


Gyakorlat: Felhasználói és kiszolgálóoldali PKI-gyakorlatok 
Virus Buster Personal Edition, 1 éves előfizetéssel 


A MesterOrzusok helyszíne: NetAcademia Kft., Budapest, Andrássy út 62. 
Jelentkezés: http:/fwww.netacademia.net/mesterg 


Bi Hl 
ACADEMIA 


MÁRCIUSBAN INDULÓ TANFOLYAMAINK: 


Ce A tanfolyam neve Kezdési időpont vé 

AD Active Directory mélyvíz március 13. 48.000,- Ft 

DIS Katasztrófaelhárítás március 14. 32.000,- Ft 

SEGIJ Betörésvédelem március 17. 32.000,- Ft 

TEP/P Hálózati ismeretek március 31. 48.000,- Ft 
a szabványok tükrében 

2355 Áttérés NT4/Exchange 5.5-ről március 18. 96.000,- Ft 


Windows 2000/Exchange 2000 
környzetre 


ASP.NET ASP.NET mélyvíz március 12. 160.000,- Ft 


http://www.netacademia.net 


A NetAcademia ezúton meghívja Önt 
és kollégáit a 2003. március 17-én megrendezésre kerülő 


DotNetNapra 


HE Regisztráció és részletek: http://www.netacademia.net/dotnetnap B 


lg ilajiT ( 
a 11 r]j ] gl gb a, kezre allo megoldas 
u Egyedülálló lehetőség a felhasználóknak 


bárki saját személyes címlistát készíthet a letöltött adatok felhasználásával 


u Speciális keresési opciókkal 


Több mint 90 000 cég, vállalkozás adatai az 
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ország egész területéről, keresési lehetőségek: 
név, cím, telefonszám, tevékenység és kerület alapján. 
A keresett cég telephelye megtekinthető térképen is 
(Budapest, Győr, Miskolc, Pécs és Szeged) 


angol és magyar nyelven egyaránt. 


www.superpages.hu 





2590 kedvezménnyel 


Kedvezményes konstrukció, rugalmas időbeosztás " A kezdő szinttől a haladó ismeretekig. 
Párhuzamosan sajátíthatja el a Visual Basic .NET és a Ct$ nyelv használatát. 
Szerezzen nemzetközi (MCAD/MCSD) minősítést! 

Microsoft A Microsoft .NET fejlesztői képzés hat darab hivatalos Microsoft tanfo- Microsoft 


CIER TNE I E.D lyamra épül, összesen öt hétben. A tanfolyamok minden hónap egy-egy CÉRTIFIED 
Application Developer hetében kerülnek megrendezésre, vagyis 3-5 napot jelentenek havonta. Solution Developer 
KM aze A a § J Ai . ella az jé) 2 
HA G G4 Cs a) A] . F A d Ő kh 
2559/2609-es tanfolyam (Visual Basic .NET és Ct.NET): 2003. március 10-14. 
2071-1-2389-es tanfolyam (adatkezelés, SOL 2000, ADO.NET): 2003. március 31-április 4. 
2555/2565-ös tanfolyam (Windows alkalmazásfejlesztés): 2003. április 22-24. 
2310-es tanfolyam (webes alkalmazásfejlesztés): 2003. május 26-30. 
2524-es tanfolyam (XML/webszolgáltatások fejlesztése): 2003. június 30-július 2. 
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